tipaul [Thu, 11 Aug 2005 16:35:54 +0000 (16:35 +0000)]
This script can be use to rebuild the zebra DB. It stores all koha MARC records in iso2709, in the bilbios directory. After that, you just have to "zebraidx update biblios"
I tried on a 9900 DB, here are the results :
[paul@bureau migration_tools]$ ./rebuild_zebra.pl -c
9900
9903 MARC record done in 37.9104120731354 seconds
tipaul [Thu, 11 Aug 2005 16:12:47 +0000 (16:12 +0000)]
Playing with the zebra...
* go to koha cvs home directory
* in misc/zebra there is a unimarc directory. I suggest that marc21 libraries create a marc21 directory
* put your zebra.cfg files here & create your database.
* from koha cvs home directory, ln -s misc/zebra/marc21 zebra (I mean create a symbolic link to YOUR zebra directory)
* now, everytime you add/modify a biblio/item your zebra DB is updated correctly.
NOTE :
* this uses a system call in perl. CPU consumming, but we are waiting for indexdata Perl/zoom
* deletion still not work
* UNIMARC zebra config files are provided in misc/zebra/unimarc directory. The most important line being :
in zebra.cfg :
recordId: (bib1,Local-number)
storeKeys:1
in .abs file :
elm 090 Local-number -
elm 090/? Local-number -
elm 090/?/9 Local-number !:w
(090$9 being the field mapped to biblio.biblionumber in Koha)
tipaul [Thu, 11 Aug 2005 14:37:32 +0000 (14:37 +0000)]
* POD documenting
* removing useless subs
* removing some subs that are also elsewhere
* renaming all OLDxxx subs to REALxxx subs (should not change anything, as OLDxxx, as well as REAL, are supposed to be for Biblio.pm internal use only)
hdl [Tue, 9 Aug 2005 14:13:27 +0000 (14:13 +0000)]
Adding lateorders page.
It provides the user with the list of items that have been ordered for a delay and are NOT yet received.
The user may filter by supplier or branch or delay.
This page is still under developpement.
Goal is to make it ready to print to reorder the books.
2 new functions have been written in Acquisition module :
getsupplierlistwithlateorders
getlateorders
branches has been modified to manage branch independancy.
Request for comment.
STILL UNDER developpment
tipaul [Tue, 9 Aug 2005 14:10:27 +0000 (14:10 +0000)]
1st commit to go to zebra.
don't update your cvs if you want to have a working head...
this commit contains :
* updater/updatedatabase : get rid with marc_* tables, but DON'T remove them. As a lot of things uses them, it would not be a good idea for instance to drop them. If you really want to play, you can rename them to test head without them but being still able to reintroduce them...
* Biblio.pm : modify MARCgetbiblio to find the raw marc record in biblioitems.marc field, not from marc_subfield_table, modify MARCfindframeworkcode to find frameworkcode in biblio.frameworkcode, modify some other subs to use biblio.biblionumber & get rid of bibid.
* other files : get rid of bibid and use biblionumber instead.
What is broken :
* does not do anything on zebra yet.
* if you rename marc_subfield_table, you can't search anymore.
* you can view a biblio & bibliodetails, go to MARC editor, but NOT save any modif.
* don't try to add a biblio, it would add data poorly... (don't try to delete either, it may work, but that would be a surprise ;-) )
IMPORTANT NOTE : you need MARC::XML package (http://search.cpan.org/~esummers/MARC-XML-0.7/lib/MARC/File/XML.pm), that requires a recent version of MARC::Record
Updatedatabase stores the iso2709 data in biblioitems.marc field & an xml version in biblioitems.marcxml Not sure we will keep it when releasing the stable version, but I think it's a good idea to have something readable in sql, at least for development stage.
hdl [Mon, 8 Aug 2005 13:55:52 +0000 (13:55 +0000)]
Managing branch independancy when creating a new biblio.
A librarian of one branch cannot create a biblio on a branch different form his own, unless superlibrarian.
hdl [Mon, 8 Aug 2005 08:42:32 +0000 (08:42 +0000)]
Code necessary for IndependantBranches parameter to work. Should have been committed sooner...
Modify Histsearch and getorders to respect branches of librarian.
tipaul [Fri, 5 Aug 2005 14:47:23 +0000 (14:47 +0000)]
2 new features :
- a mail is sent everytime an issue if recieved in serial module. The mail is sent to all borrowers that have put an alert on the subscription (remember that you can put an alert only if the librarian have defined a "letter" as mail to send)
- the librarian can see, for a given subscription, who has put an alert.
tipaul [Thu, 4 Aug 2005 08:55:54 +0000 (08:55 +0000)]
Letters / alert system, continuing...
* adding a package Letters.pm, that manages Letters & alerts.
* adding feature : it's now possible to define a "letter" for any subscription created. If a letter is defined, users in OPAC can put an alert on the subscription. When an issue is marked "arrived", all users in the alert will recieve a mail (as defined in the "letter"). This last part (= send the mail) is not yet developped. (Should be done this week)
* adding feature : it's now possible to "put to an alert" in OPAC, for any serial subscription. The alert is stored in a new table, called alert. An alert can be put only if the librarian has activated them in subscription (and they activate it just by choosing a "letter" to sent to borrowers on new issues)
* adding feature : librarian can see in borrower detail which alerts they have put, and a user can see in opac-detail which alert they have put too.
Note that the system should be generic enough to manage any type of alert.
I plan to extend it soon to virtual shelves : a borrower will be able to put an alert on a virtual shelf, to be warned when something is changed in the virtual shelf (mail being sent once a day by cron, or manually by the shelf owner. Anyway, a mail won't be sent on every change, users would be spammed by Koha ;-) )
tipaul [Thu, 4 Aug 2005 08:54:54 +0000 (08:54 +0000)]
Letters / alert system, continuing...
* adding a package Letters.pm, that manages Letters & alerts.
* adding feature : it's now possible to define a "letter" for any subscription created. If a letter is defined, users in OPAC can put an alert on the subscription. When an issue is marked "arrived", all users in the alert will recieve a mail (as defined in the "letter"). This last part (= send the mail) is not yet developped. (Should be done this week)
* adding feature : it's now possible to "put to an alert" in OPAC, for any serial subscription. The alert is stored in a new table, called alert. An alert can be put only if the librarian has activated them in subscription (and they activate it just by choosing a "letter" to sent to borrowers on new issues)
* adding feature : librarian can see in borrower detail which alerts they have put, and a user can see in opac-detail which alert they have put too.
Note that the system should be generic enough to manage any type of alert.
I plan to extend it soon to virtual shelves : a borrower will be able to put an alert on a virtual shelf, to be warned when something is changed in the virtual shelf (mail being sent once a day by cron, or manually by the shelf owner. Anyway, a mail won't be sent on every change, users would be spammed by Koha ;-) )
tipaul [Tue, 2 Aug 2005 16:15:34 +0000 (16:15 +0000)]
adding 2 fields to letter system :
* module (acquisition, catalogue...) : it will be usefull to show the librarian only letters he may be interested by.
* title, that will be used as mail subject.
hdl [Mon, 1 Aug 2005 14:36:49 +0000 (14:36 +0000)]
Adding Independant branches Management for items, i.e
Only items on the same branch as user can be created, modified, deleted.
If trying to get an item which homebranch is different from user branch AND that user is not superlibrarian, then go back to additem.
rangi [Fri, 29 Jul 2005 00:56:22 +0000 (00:56 +0000)]
If MARC is switched off, it will now jump to detail.pl instead of
MARCdetail.pl when only one result is found
This provides for a more consistent experience
Adding branch independancy management.
Showing management buttons if same branch librarian.
TODO : control of user branch before displayin modify pages.
Introducing new "Letters" system : Letters will be used everytime you want to sent something to someone (through mail or paper). For example, sending a mail for overdues use letter that you can put as parameters. Sending a mail to a borrower when a suggestion is validated uses a letter too.
the letter table contains 3 fields :
* code => the code of the letter
* name => the complete name of the letter
* content => the complete text. It's a TEXT field type, so has no limits.
My next goal now is to work on point 2-I "serial issue alert"
With this feature, in serials, a user can subscribe the "issue alert". For every issue arrived/missing, a mail is sent to all subscribers of this list. The mail warns the user that the issue is arrive or missing. Will be in head.
(see mail on koha-devel, 2005/04/07)
The "serial issue alert" will be the 1st to use this letter system that probably needs some tweaking ;-)
Once it will be stabilised default letters (in any languages) could be added during installer to help the library begin with this new feature.
For instance, the return date does not rely on the borrower expiration date. A systempref will be added in Koha, to modify return date calculation schema :
* ReturnBeforeExpiry = yes => return date can't be after expiry date
* ReturnBeforeExpiry = no => return date can be after expiry date
Implementing Independancy Branches management :
- Trying to get a basket not owned by so of his own branch leads to mainpage.
- Lists onlys ths baskets owned by someon of user's brach.
Auth.pm now sends a cookie with userenv informations.
Bug Fixing for independantBranches support.
Addign a Cookie containing user specific vars such as :
branch,
firstname,
surname,
cardnumber...
may be criticized from a lawyer point of view, since name and surname are given.
But the real need is for userid and branch.
And it is achieved.
Auth passes now TWO cookies :
a session cookie
And an environment cookie.
we have decided that moving to Koha 3.0 requires being already in Koha 2.2.x
So, the updatedatabase script can highly be cleaned (90% removed).
Let's play with the new Koha DB structure now ;-)
First draft of programmer's templates: a stripped-down version of the templates for use by programmers in adding and testing new functionality. Template-authors can use these templates to track changes that need to be incorporated into their custom templates.
First draft of programmer's templates: a stripped-down version of the templates for use by programmers in adding and testing new functionality. Template-authors can use these templates to track changes that need to be incorporated into their custom templates.
First draft of programmer's templates: a stripped-down version of the templates for use by programmers in adding and testing new functionality. Template-authors can use these templates to track changes that need to be incorporated into their custom templates.
First draft of programmer's templates: a stripped-down version of the templates for use by programmers in adding and testing new functionality. Template-authors can use these templates to track changes that need to be incorporated into their custom templates.
First draft of programmer's templates: a stripped-down version of the templates for use by programmers in adding and testing new functionality. Template-authors can use these templates to track changes that need to be incorporated into their custom templates.
Adding Log Facility.
Needs Two Update in database...
On more table (action_logs)
And One more syspref Activate_Log, with On|Off values.
Maintainance has been sweeped of previous Log functions
addbiblio.pl contains a sample of code using Log.pm
To be generalized to Authorities, acquisitions, members soon.