Hi all, thd and I have introduced some additional complexity into the MARC frameworks that offers a more complete handling of tag and subfield visibility. It's completely backwards-compatible so if you're happy with your current visibility options you don't need to do a thing and everything will behave exactly as it did before. First, I should introduce the problem: with the old scheme, there was a flag (INT(1)) that allowed hiding a subfield in the OPAC. You could also set a subfield to 'ignored' which was used for the special tags/subfields whose values are managed internally (e.g., 090). This would probably have sufficed but for the fact that thd has been working on a complete 'Standard MARC21 Framework'. In testing this framework (which includes 2/3s more fields than 2.2.5's default framework), we discovered that it was unusable due to long page loads (it's really quite a huge form with about 3,500 fields defined). (just to give you an idea of how slow it was, it took about 90 seconds to load a blank 'addbiblio' page and about 2-3 minutes to save a populated record). In addition, there is the problem of usability. With so many tags and subfields on a page it's very difficult to identify the most commonly used fields -- they are lost among the uncommon and rare fields. So we set out designing a 'visibility scheme' with three basic goals: 1. prevent very rare tags/subfields from being loaded into the MARC editor by default, but allow the user to add them if needed (with a page reload) and _definitely_ load them if they already exist in a record (ie, _no_ data lost when using the MARC editor). 2. allow uncommonly used fields to be collapsed and expanded quickly and easily without a page reload. 3. preserve the legacy 'hidden' functionality so the new framework isn't required for the upgrade to 2.2.6. As it turns out, there are quite a few possible visibility conditions that should be properly dealt with in a future version of Koha. Using the current framework's 'hidden' database definition (INT(1)) we can account for up to 19 such conditions (values -9 thru 9). Given that limitation as well as our current time constraint, we identified 17 conditions that will be defined in the new 'Standard MARC21 Framework' plus a 'Flag' condition that can be used to flag subfield definitions that will need to be revised when the framework can handle more conditions (ie, in 3.0). The scheme we devised is the following: ( ! means 'not visible' or in the case of Collapsed 'not Collapsed') -9 => Future use -8 => Flag -7 => OPAC !Intranet !Editor Collapsed -6 => OPAC Intranet !Editor !Collapsed -5 => OPAC Intranet !Editor Collapsed -4 => OPAC !Intranet !Editor !Collapsed -3 => OPAC !Intranet Editor Collapsed -2 => OPAC !Intranet Editor !Collapsed -1 => OPAC Intranet Editor Collapsed 0 => OPAC Intranet Editor !Collapsed 1 => !OPAC Intranet Editor Collapsed 2 => !OPAC !Intranet Editor !Collapsed 3 => !OPAC !Intranet Editor Collapsed 4 => !OPAC Intranet Editor !Collapsed 5 => !OPAC !Intranet !Editor Collapsed 6 => !OPAC Intranet !Editor !Collapsed 7 => !OPAC Intranet !Editor Collapsed 8 => !OPAC !Intranet !Editor !Collapsed 9 => Future use With this scheme, it's quite simple to check for the most important cases: *if (odd) { collapsed } *if (even) { !collapsed } if (>=0) { hidden in OPAC } if ((<=-4)||(>=5)) { not in the editor unless exists or is added} Those four checks take care of all the goals we set out to achieve. Of course, there are finer distinctions to be made, but we'll leave that for a future version. So just to clarify, we've implemented a subset of the scheme we devised -- a subset that doesn't comprimise where it counts (ie there won't be any data loss as with Koha 2.2.5). If you want to try out the new system feel free to use LibLime's demo: http://koha.liblime.com/cgi-bin/koha/acqui.simple/addbiblio.pl You'll notice that some tags (take 040 as an example) are listed but the subfields within them aren't -- simply click on the little + graphic to expand the fields (no page load) Likewise, some very rare tags/subfields don't appear by default. However, if you do a Z3950 search for a record and one contains them they will appear when you import the record (they will also import if they exist in records in the database). Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS