Wolfgang Pichler wrote:
[snip]
I principle you could use user_ldap_id for this purpose, as long as
you don't enable the LDAP functionality in Emilda. On the other hand
it is very easy to manually add custom fields in the database, and
with the current database API they shouldn't interfere with Emilda in
any way (which ldap_user_id will do). You just have to keep track of
and update these fields via your external user handling script (unless
you implement something inside Emilda).
great. i will come back with books/book-barcode-printed later :-)
I can't promise that a barcode_printed field will fit into Emilda, but
the patch should be easy for you to maintain.
[snip]
1) at the end of each period of administration (schoolyear,
calendaryear, quartal, whatever ...) :
a) all relevant data for users/user-id is fed freshly from external
data via key users/user-ldap-id
b) users/user-card-number is saved to users/user-card-number-last-seen
c) users/user-card-number and users/user-password are set empty to
disable any activities
d) users/user-privileges are set to 0
Actually disabling the user account in Emilda is almost equivalent to
c) and d). And I wonder if b) is needed at all, since the card number
can be overwritten at any time and hence the current number can stay
in the database until a rewrite is needed.
disabling is to prevent usage of this user-id. if this can be achieved
by otehr means all this saving and restoring is USELESS.
The privilege called "ENABLE" handles this. It prevents usage of an
account. It doesn't hide the user or check for borrowed/reserved books.
Perhaps we should consider some procedure for that.
[snip]
problem not yet discussed is how to return books if user is "disabled"
(no card-id or whatever indicators to prevent "normal" usage) ...
Books can be returned regardless of the state of the borrower. The
process only returns the book(s).
SCENARIOS
A) a person will present an "old" id-card with a label containing an
"old" group membership on it
1) we scan the "activation-barcode" on the "old" label and the card-id
(data is checked for consistency and possible "mistakes" of the user)
2) we look check relevant personal data (remember we should see the
latest)
3) we assure no borrowed books exist, no due charges, etc.
4) we ask the person to type in his/her personal password twice
5) we stick the "new" label on the "old" id-card and scan the
"activation-barcode" to commit usage permission for the "next" period
- users/user-card-id will be restored
- users/user-password is inquired and set accordingly
(remember: all other things as privileges, group managment, etc. were
fed before)
6) anything left ?
This seems rather complicated to me. Sure, it might be worthwhile to
have an activation-barcode in order to make users visit the library
for reactivation, but the manual data-moving process could as well be
skipped.
see answer to thread before : to minimize patron's work it would be fine
to just scan barcodes to smoot h "rotation"("promotion")
But actually this activation code could be anything from a passphrase to
the user's actual card id. I just fear that a second barcode on the card
will confuse users (or even the system, if the wrong barcode is scanned
by the laser beam before the actual card-id).
[huge snip]
in an automated environment (batch promotion) you will still have to
write all personalization except card-id onto the id-card (at least
names) and stick it.
ok. you have to do it ONCE, not every year (or period).
but i think it is still more cost-effective to produce "blind" id-card's
and personalize them on demand (so at least once).
Once is ok, it's the activation barcode sticker system I'm not sure is
needed.
[snip]
just assuring no conflicts with legacy processing within emilda.
you are welcome to use any code co-developed for these purposes.
That's what this list is for =) We must look at this issue in a larger
perspective until we can produce/accept any code changes. A detailed
description, paper, plan or schema would be a good start. Implementation
post 1.2, of course.
Regards,
--
Erik Berglund
Partner, Marketing
Oy Realnode Ab
lastname@xxxxxxxxxxxx
www.realnode.com
|
