Erik Berglund wrote:
Wolfgang Pichler wrote.
clarification on promotions / "activation" :
assumed, one could use table/field users/user-ldap-id also for non
ldap related (external) identification of users
assumed, we will promote users/user-ldap-id to "key" to speedup things
assumed we have some additional users/field
user-last-seen-card-number as key to speedup things
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 :-)
0) we will lots of plastic thingies with preprinted card-id's
starting from 00000000000001L and some basic data on it like URL of
library, etc.
Preprinted cards are certainly more tangible than barcodes on a list
=). We have actually planned to produce a simple A4 template for these
"cards", see bug 156. As a side note I'm curious to know how you have
produced and/or how you will produce these library cards (or do you
order them from somewhere)? We could use some ideas in that field.
i have a firm in our next village which produces those very plain
black/white cards @ about eur 0,50 incl 20%vat (may vary)
but you might try also http://www.plastikkarten.info/rechner.html
(german only alas) but the above is a mean price throughout all firms ...
(Btw I just noted that we probably don't support US letter size
printouts. Making a (bug)note of that.)
aglophile users will be happy :-)
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.
Step a) however is more relevant, but I would suggest doing this when
adding or re-enabling the user, since the data can be more fresh at
that time (by some magical data update process).
step a) is the key to achieve actual data.
2) new group(s) are established reflecting
a) the period of administration
b) the "current" target groups
e.g. 2004-3A, 2004-5-staff, ...
If a new group is needed simply because the group name (and/or
description) has changed, I would suggest editing group descriptors in
stead of removing/adding groups entirely. But again I might have
misunderstood your intentions here.
i want users to belong to a group for
administrative/consistency/tracking reasons.
so user can be member of 2004-3bc and member of 2005-4g (but did not use
the library in 2005) and use the library again as member of 2006-5g
problem not yet discussed is how to return books if user is "disabled"
(no card-id or whatever indicators to prevent "normal" usage) ...
3) table linkage is populated accordingly from external data to
reflect the "new" meberships
4) we print labels containing relevant human-readable data well
sorted to aid fast lookup by libraryoperator and an "activation-barcode"
POSSIBLE VALUES (please feel free to to discuss this ; i could not
identify an optimal solution yet since the idea is too "fresh" but i
think it should be shared anyway :-)
- users/user-id
- users/user-ldap-id
- additionally desired group membership for this period
- ?
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 perhaps I'm viewing this from another perspective; let me explain:
I presume that you are trying to achieve an active-users-only, fresh
database for each semester/period/year. I.e. only those users who
really use the library will be active in Emilda, the rest will be
stored somewhere else for import if necessary.
the import is triggered by scanning the "activation-code"
Re-activation would require a visit to the library, which will ensure
some interaction between patrons and librarians. Am I somewhere close
to what you intended?
yes.
In our test environment (at a school here in Finland) all new students
are manually added into Emilda at the beginning of each school year.
The names of existing groups are changed when necessary, 4A becomes
5A. A few users who have changed groups are moved accordingly. Some
users have left the school and are deleted (with backups in place for
emergency restore).
The key question is how the users are added/imported/enabled, and this
is exactly why we have introduced LDAP functionality in Emilda. LDAP
was asked for in order to enable interaction with an existing
ActiveDirectory database that handles usage rights to workstations at
the school. I.e. that database contains information on all active
students and personnel which Emilda can use as base for user creation
and updates. Only names and group (class) information are needed, and
now the school secretary can update a student's name in all systems
simply by changing the information in AD. New students are imported
into Emilda from AD by the head librarian, she simply links an Emilda
user account with data from ActiveDirectory. And the scenario works on
any central LDAP database, not only AD. This all in theory, we have
yet to conduct a live test on this.
AD "sucking" is fine, but remember, there are many schools using crazy
stuff like NOVELL and not M$.
so 2 possibilities are left :
- establish OPENLDAP and feed it by exporting from sick
staff/pupil-administration programs for schools (in austria e.g. SCHÜSTA
- aargh :-( )
- feed some MYSQL from the same sources
But if LDAP is not an option, and you want to "clean" the user
database at the end of every year, and re-enable active users at the
beginning of the next, we need to consider some automation alternative
like the one you have suggested. But I would simplify it somewhat:
Why not move _all_ data to a backup location? In principle the system
works the same way even if the entire user row is deleted. A special
tool could be created for import of deleted users, and it would simply
copy data from a backup database into Emilda. Linkage needs to be
taken care of, but that problem remains no matter how you do this.
that utility would be triggered via scanning of the "activation-barcode"
:-)))
Patron accounts would be reactivated based on their permanent id/card
number. Data validity can be checked during reactivation. No need for
separate activation codes or new card numbers, simply re-insert a
previously deleted row, check/update linkage and voilá!
as stated teh activation-code is just another method. it resides on
label-sheets printed at ghe beginning of each year (or whenever
user-data changes during the year) and contains e.g.
- family name
- given name
- group membership (implicitly : period of validity)
- ???
these label(-sheets) are grouped by group and at hand for the patron in
his locked drawer.
B) a person will insist to be a "new" user
1) we browse thru our database to verify this condition
2) in case an "old" id-card was issued before we correct our data
silently to reflect a "freshly" issued id-card and give the old one
no chance again
3) A)3) - A)6) with the "new" id-card
A new user is a new user is a new user. Use user add for this purpose,
and remove the old data from the "deleted" database if necessary. If
the same card number is used, simply enter the old number while adding.
you are right. but it was never intended to reissue new card-id's every
year ...
for that reason i would need the card-id-last-seen if no other mechanism
exists.
C) a person needs a "new" id-card for various reasons : see B) esp. B)2)
Card numbers can be changed dynamically and other user data can be
updated. New cards with the same card number can be printed/ordered. A
totally new account can be created.
REMARKS
i suppose, that the "ldap"-effort has much of this back in mind and i
would not hesitate to use it accordingly.
if i am right, could you please unhide some rationale behind it, an
more important clarify the implicitly required administrative tasks
and data-structures (e.g. what to put on an id-card and why, how to
"rotate" users without pain, etc.)
See above.
i guessed right :-)
i think it is very important for the library staff to contact users
as much as possible and some sort of personal "registration" will help
True, but this should be an option for each library to choose. In some
cases personal registration is too complicated and time-consuming,
which is the case at our (small) test location where there is no
actual library personnel and one teacher works a few hours per week at
the library desk.
automated "rotation"/"promotion" would just be a batch ...
and last but not least it is more cost-effective to print a bunch of
unused (waterproof) labels than unused id-cards. we have 1200+ pupils
100+ teachers and only 200-300 active users which direct their steps
towards the library ....
Or then we stick with the first id, hence eliminating the need for any
new prints at all.
see above.
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).
bottom line - if all of this is not a good idea and just a
complication let's drop it and i am interested how others think about
"rotation" and how to implement it smoothly.
---
sincerely
w.pichler
It _is_ a good idea, and it's also very good that you have brought
this up for discussion. Rotation should ideally be an automagical
process, and any effort to improve current functions is very welcome!
just assuring no conflicts with legacy processing within emilda.
you are welcome to use any code co-developed for these purposes.
---
w.pichler
|
