The custom file need only contain the properties that you wish to change.
The xul <messagecatalog id="commonStrings" src="/xul/server/locale/<!--#echo var='locale'-->/common.properties" /> will attempt to parse both common.properties and common_custom.properties
senator [Sun, 12 Sep 2010 19:03:01 +0000 (19:03 +0000)]
Serials: dojo/autogrid-based scaffolding for building serials objects
Accessible from the staff client OPAC browser's "Actions for this Record" menu
as "Alternate Serial Control", these minimalist interfaces should support a
workflow by which the user can create a subscription and its related parts
(distributions, streams, etc), and get things going in a quick and dirty way
while the existing Serial Control View continues to develop.
Some notable differences in orientation between this and the existing
interface work include:
- The disuse of call numbers on distributions, instead favoring call number
application to items by issuance at receive time (i.e., all copies of
the Sep 2010 issue of Popular Mechanics share a call number rather than
all copies of Popular Mechanics, any issue, at a given library sharing a
call number).
- Lack of attention to binding (although the batch receive interface will
treat each item as a single bound unit, for barcoding, or will avoid
creating units altogether if you don't want to barcode your serials).
If this doesn't sound like the way you would do serials, I'd definitely
recommend sticking with Serials Control View and ignoring these interfaces.
Dan Wells' interface work promises broader functionality in the long run.
senator [Sun, 12 Sep 2010 00:12:26 +0000 (00:12 +0000)]
Serials: support predicting issuances until a specified end date
Previously you could specify a number of issues, or possibly a final holding,
but if you haven't created the final holding yet, but you know when the
subscription ends, this can be useful.
add "type" (siss.holding_type) and "status" (sitem.status) filters; renaming the method to be explicit about the fact that it is for issuances with received (sitem.date_received IS NOT NULL) items /only/
senator [Fri, 10 Sep 2010 22:24:44 +0000 (22:24 +0000)]
Add "refresh grid" buttons to some consistently glitchy autogrids.
This is obviously not an ideal solution, but if the user sees these grids
and it's clear that not all the rows that should appear are rendering, they
at least have a button to click to deal with it. There are probably other
places where this could be applied.
'use parent' consistently throughout OfflineStore.pm
If we're going to use "use parent" instead of "use base" when creating
the child instance of Class::DBI 3.01 that is OpenILS::Utils::OfflineStore,
we might as well be consistent when declaring its own children.
In list.fm_columns, allow us to dictate the data object used for rendering (the row.my object fed into list.append) for all columns via the '*' column definition. Also, wire up mailing and billing address columns into Patron Search
Give the ability to duplicate column definitions by prefixing their id's. Allow the specification of alternate row objects and datafields to render from. The idea is to let us do such things as list address columns for a patron twice, once for the billing address and again for the mailing address.
move Patron Search over to fm_columns instead of patron.util.columns (the former makes use of fm_IDL.xml and can automagically make use of new fields, etc.). Also give fm_columns the ability to hide virtual fields from the column picker
the method behind patron.util.retrieve_fleshed_au_via_id can take a fields parameter for which fields to flesh, so let's expose that, and flesh some patron data being sent to receipt templates while we're here. End-goal is to expose address information in patron searches without sending too much data over the wire
Enable Class::DBI::Frozen::301 use for offline transaction management
Most modern systems will install Class::DBI::Frozen::301 to avoid
conflicts with incompatible Class::DBI packages. We need to teach
offline.pl how to use Class::DBI::Frozen::301 if it is available.
Note that we're using "use parent" instead of "use base" per the
recommendation of "perldoc base"; accordingly, we're adding the
system prerequisite for the parent pragma.
Remove the previously deprecated CGI interfaces for configuring the Evergreen system
The CGI interfaces have not been maintained; the interfaces available through
the Admin -> Server Administration menu in the staff client are the recommended
method for setting up new libraries in the organizational hierarchy,
permissions, copy statuses, and circulation rules.
Note that an adjustment to eg_vhost.conf is recommended to point to the
offline.pl script, which is the only remaining CGI script in use; this
should avoid conflicting Apache definitions for the /cgi-bin/ alias.
senator [Fri, 10 Sep 2010 02:15:06 +0000 (02:15 +0000)]
Booking: stop the "new resource type" dialog from executing a naughty query
The dialog will no longer offer a field for selecting a bibliographic record,
but then again you wouldn't need it. Bibliographically-based resource types
can be set up through a context menu option in the staff OPAC browser, whereas
this interface is only suited to non-bib-based resource types, like meeting
rooms, laptops, etc.
put these buttons under the sway of Dojo so that they don't get triggered when pressing enter in random fields in the patron editor form. I have no idea why this works :)
senator [Thu, 9 Sep 2010 21:28:20 +0000 (21:28 +0000)]
Improve on 17547 to support a default value for /creating/ new objects while
letting the current value of an object pass through to the overriding widget
when /editing/.
Styling tweaks to brief bib summary bar. More tooltips, and expose record id and bib call number (from the first available defined in the appropriate asset.call_number_class entry)
senator [Thu, 9 Sep 2010 13:44:18 +0000 (13:44 +0000)]
Serials: pattern wizard bugfix
Previously, you couldn't always compile the pattern at the end of the wizard
if you elected not to use certain parts of the wizard, such as enumeration
captions, even though to do so should be perfectly valid.
make the table rows containing stat cats in the patron editor more easily selectable by CSS. So, for example, we could put something like this in register_custom.css: TR[stat_cat_id='1'] { border: solid thick red; font-size: x-large; }
We briefly had to grab Library::CallNumber::LC from the SVN repo, but
that broke on systems without subversion installed (argh). Thankfully
the maintainer moved Library::CallNumber::LC to CPAN so our job becomes
routine.
Thanks to Chris Sharp and Benjamin Shum for running the gauntlet of a
2.0 alpha install and finding this problem.
* move inline CSS in patron editor to a file
* hook for custom CSS file to override patron editor styling
So for example, you can create /openils/var/web/css/skin/default/register_custom.css and have it contain CSS like this:
TR[fmfield=ident_type] { display: none; } /* dangerous if the widget is required and doesn't have a default */
TR[fmfield=ident_value2] > TD { font-size: x-large; }
TR[fmfield=barred] { display: none; }
TR[fmfield=country] { display: none; } /* dangerous if the widget is required and doesn't have a default */
TR[fmfield=master_account] { display: none; }
TR[fmfield=alert_message] { display: none; }
We were shoving a fieldmapper actor.usr object into hold slip templates as params.data.user, but that environment doesn't have fieldmapper, dojo, etc. To sidestep some difficulties adding such libraries, this takes user stat cat entries and shoves them in as normal Javascript objects (params.data.user_stat_cat_entries)
So you can add something like this to the hold slip template:
<script>
var x = params.data.user_stat_cat_entries;
for (var i = 0; i < x.length; i++) {
document.write(x[i].stat_cat.name + ' : ' + x[i].stat_cat_entry + '<br/>');
}
</script>
However, such pig-trickery with inline Javascript only works with the Mozilla Print strategy (where we render HTML and execute Javascript).
disabled lib menu entries in Holdings Maintenance was an artifact of that menu data being generated and used in other contexts. This enables all the libs for the menu in Holdings Maintenance
Tweaked Holdings Maintenance so that it only shows the selected library, its ancestors, and its descendents, subject to a Limit menu for org depth (so for example, in the stock example hierarchy where you have Consortium -> System -> Branch -> Sub-Library/Bookmobile, if you Limit to Branch, you will not see any Bookmobile or Sub-Library orgs). It no longer renders sibling libs when clicking through the list.
Also...
* some refactoring and comment removal
* less obtrusive but hopefully still useful menu entry styling for library entries that have volumes
* some defensive coding for util.make_menulist
cache the SIP login session to determine 'where' a transaction is occuring in case the caller does not indicate the location; compare hold pickup lib to physical location to determine alert type; small logging and format tweaks
Move some operations out of the transaction so that they can
fail without killing the script. The affected objects do
not necessarily exist -- i.e. the reporter schema, the
extend_reporter schema, and the auditor.action_hold_request_history
table.
1. Inserts and other changes to permission.perm_list and
permission.grp_perm_map. These can't be derived in a simple way from
the individual upgrade scripts, and will have to be hand-crafted to
fit what's already in the seed data.
2. Operations on optional schemas need to be moved out of the
transaction so that the script will work in a database that
doesn't have them.
senator [Fri, 3 Sep 2010 16:30:47 +0000 (16:30 +0000)]
Serials: a wizard for the pattern code field of the caption_and_pattern object
This field holds the same data you'd find in the contents of an 853, 854, or
855 tag. This wizard aims to make it a little easier for mere mortals to
compose this information, since the correctness of this field is fairly
central to reasonably accurate serials issuance prediction.
Find a button to launch this wizard from the Caption/Pattern interface of the
Serial Control View.
Big thanks to Galen Charlton, Dan Wells and Mike Rylander for all the help in
getting this started and understanding the MARC.
The wizard does still have a way to go before it's everything it can be. It
still needs (in no particular order):
- scrollbars on that dialog window
- support for subfield $y and probably $z, possibly others
- i18n fixes, accessibility improvements
- more control over subfield $8
- more input validation and user guidance; sane defaults for some fields?
- reconsideration of the order of the parts of the wizard
- finding out if it makes sense to allow $m without $j,$k and $l present