Bob's ramblings on what opendispense2 should have and why, coutesy of a 5 hour flight to Sydney (will reorder it, format it and fix it later). Feel free to argue with me at any point too:

• Comments by TPG in italics

Goals:

• enable non-members to use the coke and snack machines, while maintaining the same user experience for current members

  • Good idea

• structure dispense so that a coin/note machine can be used to add credit

  • That is actually possible at the moment (just use a "coin-server" that does dispense acct

  • not possible for non-members though, since they don't have any way of authing.
• ensure that server doesn't depend on any external auth mechanism (clients can still pull usernames from PAM). This reduces external dependencies (both hardware and software) and should increase the lifetime of the server)
• fix all of the major problems (especially accounting) of the current version of dispense

Non-member has:

• no club account/login
• a smartcard
• money!

Problems with the current dispense:

• credit never expires. This means that the total dispense liability never goes down, and we can't properly account.
• config files are all over the place, wtf is with having several copies of coke.controllers?
• limits on length of drink names
• not recompilable (well duh), hard to move
• no perks for coke members. Yay you can go $20 in the negative, which causes the treasurer to hunt you down and the annoying daily emails.
• rorting scripts work
• you can go negative. You should't be able to go negative because:
  • it's a false perk (as explained above)
  • it pisses off the treasurer because we have less cash to use
  • causes issues when coke controllers leave the club when they're in debt.
  • there isn't any need (if you're buying for someone else, put the money in the safe, add it to your account, then dispense)
• case sensitivity (or not)
• 'membership' item only has one price
• can't detect locked accounts as our auth machanism has changed
• no way of deleting old users
• no easy way of knowing cumulative sales
• door logs shouldn't be in drink logs
• snacklog+cokelog not displaying useful data (each snack dispense uses 4 lines of logs)
• snack machine pins are stored in home directories - can't use snack without a ucc account
• overkill on features, most are now broken (data charging especially)
• can't put comments on gives
• no record of who set prices or when
• 'oday mode' is bad for accounting and logs
• snack server using the oday account is FITH
• door and door status all hard coded afaik
• impractical (impossible?) to set up for use with a coin machine

Some Solutions:

• make credit expire 54 weeks after last use, this isn't the best thing for accounting, but allows for those people who use dispense for long-term mebership credit storage
• give coke members a 4c discount on all drinks above 50c (conditions apply)

  • A good idea, but DON'T hard code it

Why stuff shouldn't rely on ldap and unix groups:

• Personally, my groups seem to get dropped every other day, so I'm not keen on relying on our groups setup for coke controllers
• want to be able to let non-members have dispense accounts, this can't be done with ldap afaik
• the dispense/door server should be able to run standalone without other machines, a lesson learned when servers had to be moved after the GSOP. If we put the machine on a UPS, it can be used to make the door server more reliable too

So how all this might work

Server:

• must maintain its own list of accounts in some sort of database
• db must have flags for coke controller and 'account disabled'

Client:

• only trusted clients allowed (identified via address, shared key or whatever). I can't figure out a good way of allowing untrusted clients, or why it would be necessary, but that's open for debate.

  • Allowing password authentication from untrusted clients would be a good feature (allowing a secure web-dispense)

• should pass the account name to the server and not require a password from the -user
• still trying to work out how snack client works with all this. It will probably end up being that non-members won't have a keypad login and pin.

  • The snack server is interesting at the moment, as the UIDs used are the Unix UIDs, which according to [DAA], are not guaranteed to be unique

What about situation where a non-members has a card registered and then wants to become a member?

• when a card is registered by a member, do a check for the card in the non-members. If found, add the card and the balance to the member account, and delete the card from the non-member account.
• what about when a member becomes a non-member but still wants to use their card????

  • Simple, just have the card ID be part of the user's CokeBank entry, if the user is not a UCC member, the username is NULL (or a flag is set/unset)

Treasurer Accounts Please:

• expired credit - all expired credit gets moved here

  • Bookkeeping accounts (the current version has two, ">liability" and ">sales")

• free event items - for beer nights, oday, etc. What the item *would* have cost goes here. Still not sure about this one, will confirm.
• drink sales
• snack sales
• other sales (printing, shirts, membership, etc.)

• *Since logging will be improved, do we need an extra account for each type of item?

Note to self: smartcard number must be serverside, since the client won't know about non-members

Account_Table

• acc_name
• balance
• date_last_used
• account_enabled (boolean)
• coke_controller (boolean)
• can_go_negative (boolean). Only for certain sales accounts which specifically require it, not for coke members.

Card_Table

• smartcard_id (sort by this for fast lookups)
• acc_name

Database structures: Ow, my head hurts....