are in order:
Right now there are three stylesheet sysprefs:
opacstylesheet - an external stylesheet specified by URL (replaces all other
stylesheets)
opaccolorstylesheet - local stylesheet specified by filename
opaclayoutstylesheet - local stylesheet specified by filename
Adding two functions in Biblio.pm : getitemlocation and getitemstatus (helpful to get location list and status list, status is supposed to be in relation with items.notforloan)
Adding a new function in Bull.pm : serialsitemize which take serial id and item information and creates the item
Modifying statecollection to add a new line (used for data input)
* as the MARC editor begins to be really heavy, i've also added a marc_hide systempref. It hides all marc features not requested by libraries that want MARC but not too much. It hides MARC tag & subfield code, reordering buttons as well as indicators. by default, hide_marc is off
Manage a note for a serial number...
Will allow a librarian to say "contact with supplier for this serial : Will be received on date... " or anything else.
- management : means the user can manage library parameters, but NOT system parameters.
- parameters : means the user can manage all parameters (including system parameters : marc structure, authorised values, system preferences. Was the only flag previously existing)
- tools : means the user can import/export datas & edit barcodes.
note that for compatibility reasons, a user having "parameters" can access everything.
* new permission scheme. In every template new variables are available. They are written CAN_user_permission, with permission being one of the permission flag. templates can now show or hidde menu entries depending on user permissions. For example, a user with just circ permissions should have only the "circulation" button on home page. Templates are NOT updated in this version (except for system parameters, as proof of concept), they will be in the next ones. But the scheme is ready.
This field is useful when the callnumber contains no information on the room where the item is stored.
With this field, we now have 3 levels of informations to find a book :
* the branch.
* the location.
* the callnumber.
This should be versatile enough to solve any storing method.
This hack is quite simple, due to the nice Biblio.pm API. The MARC => koha db link is automatically managed. Just add the link in the parameters section.
* acquisition rewritte : create a aqbasket table to deal with "bookseller order header".
* add "close basket" feature : a closed basket can't be modified
* suggestion feature : manage suggestions in acquisition (after suggestion filled in OPAC)