user promotion

Ł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

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.

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

2) new group(s) are established reflecting

a) the period of administration
b) the "current" target groups
e.g. 2004-3A, 2004-5-staff, ...

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 ?

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

C) a person needs a "new" id-card for various reasons : see B) esp. B)2)

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.)

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

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 ....

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

emilda rules - in near future at least :-)