Wolfgang Pichler wrote:
Łukasz Wilke wrote:
W liście z wto, 26-10-2004, godz. 20:09, Wolfgang Pichler pisze:
---
[[ off topic :
for USERS we will have some sort of activation system with :
- preprinted user-cards showing up code39 -c "card_id"
- preprinted labels with am autogenerated unique activation-barcode
which links to external data which will be fed into
emilda's user/group tables every year
mechanism :
- users are deactivated at the end of each (school-) year
- at the beginning of the year all the data of all users (of all
classes) will be
- fed into some db-space with primary key "activation-id" for every
(potential) user
- labels are printed containing name, year,class,barcode /w activation-id
and deposited ready for use of the library-administrator
- if an "old" user wants to use the library
- he will pesent his "old" id-card and receive a "new" label affixed
on the card
- library-administrator will start some little gui, read activation-id
and card-id
this utility will tweak emilda's databases, voila, user is able to
use the library for 1 more year
- same for a new user which will receive his/her "new" id-card
Sounds great !
Some time ago I've written simple library system, it had an option that
my librarian friends find attractive. It's "promoting" users after
school-year end. If before promotion "John Kowalsky" was a member of "1
A" class, after promotion, he was member of "2 A" class. Ofcourse
"promotion" function was available only when all books were returned to
library.
I think this functionality would be useful in Emilda, however there are
no classes, but "groups', which can be set quite freely, not necessarily
in "digit letter" style.
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).
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.
(Btw I just noted that we probably don't support US letter size
printouts. Making a (bug)note of that.)
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.
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).
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.
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. 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. 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?
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.
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.
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á!
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.
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 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.
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.
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!
emilda rules - in near future at least :-)
1.2 will be awesome, not to mention a future 1.3 =)
Regards
--
Erik Berglund
Partner, Marketing
Oy Realnode Ab
lastname@xxxxxxxxxxxx
www.realnode.com
|
