MARC::Record objects coming in from the reservoir are probably going to
be encoded as MARC-8. This enures that they will be converted into UTF-8
before being displayed to the user (if they are in fact MARC-8). It's most
easily done by turning the record into a MARC::File::XML object and then
going back to MARC::Record -- easiest to do for me that is. Of course, a
better solution is to create a routine that changes the encoding of a
MARC::Record object (I was surprised to find such did not exist). I have
tested this method for MARC21, but I'm not familiar with the issues with
encoding in UNIMARC: are UNIMARC records ever encoded in charater sets
other than MARC-8 and UTF-8? (if so, I will need to adjust this code).
Previous commits replaced the use of the MARChtml2marc
routine with a MARChtml2xml that reads in the form data and
converts it to a MARC::File::XML object. It then passes that
to MARC::Record via the new_from_xml() method.
This works perfectly and fixes all of the bugs with the old
MARChtml2marc routine (see mail to koha-devel). However,
there is one gotcha. The MARC::File::XML new_from_xml() method
converts UTF-8 data into MARC-8 by default for historical reasons.
This means that entry of characters outside the normal ascii range
in UTF-8 will come out as gibberish in MARC-8. Never fear, there
is a solution.
This commit uses code written for MARC::File::XML version 0.82 to
add the ability to specify the encoding desired (I chose UTF-8
because I can't think of a reason to ever need MARC-8)
The bottom line is that to properly encode records YOU WILL HAVE
TO UPDATE MARC::File::XML to at least CPAN verion 0.82 !!!!!
* 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
* in acquisition module, an order can be modified/recieved/closed only by a librarian from the same branch than the librarian that created the basket.
* in catalogue module, an item can be modified/deleted/created only by a librarian from the same branch as item owner branch
* in members module, a member can be created/modified only by a librarian from the branch of the member.
Modifying Context.pm :
Adding userenv context variable.
Is set during checkauth or get_template_and_user
Modifying Auth.pm function checkauth : setting userenv context variable
Modifying Acquisition.pm:
* histsearch
* branches
* bookfunds
* getsupplierlistwithlateorders
* getlateorders
* getallorders
* getorders
Add a branch criterium if IndependantBranches is set.
Modifiying Suggestion.pm:
* searchsuggestions Will look first for th Librarian Branch and restrict search to suggestion made by users from this branch
* countsuggestions Will look first for th Librarian Branch and restrict search to suggestion made by users from this branch
File Modifiying :
* admin/aqbudget.pl adding a branch selection for budget.
* parameters/aqbudget.tmpl
* admin/aqbookfund.pl adding a branch selection for bookfund
* parameters/aqookfund.tmpl
And adding branch selection to members and items changes.
WARNING: bibid are still used in additem, unlike in HEAD... Shall be soon fixed.
* Leader management.
If you create a MARC tag "000", with a subfield '@', it will be managed as the leader.
Seems to work correctly.
Now going to create a plugin for leader()
- Enabling Selection of Default Framework, event though it wasnot the framework of the biblio.
Adding
- Saving Framework Changes when editing a biblio.
Display improvements
We now use the official Koha API for search in the catalogue. It means the user don't have to write the title exactly as in biblio.title (empty words are now excluded)
kados
tipaul
hdl
oleonard