Goals:

• enable non-members to use the coke and snack machines, while maintaining the same user experience for current members
• structure dispense so that a coin/note machine can be used to add credit by members and non-members
• 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, name length issues, capitalisation issues, and licensing issues) of the current version of dispense

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, hard to move and add clients
• 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, and the info goes to 2 different 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
• 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)

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

• want to be able to let non-members have dispense accounts, this can't be easily done with ldap
• 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, door controller, and 'account disabled'

Client:

• only trusted clients allowed (identified via address, shared key or whatever)
  • 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 (on trusted machines)
• 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, since that requires them to have a unix UID (and the UID isn't even 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 and credit????

  • 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?

This was just a suggested layout, the final db layout ended up being quite different!

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