[SUCS Devel] Data held on membership

[Andrew Price]

On 13/07/07 10:04, Chris Jones wrote:
> So a few questions
> What data is relevant, what is not? What data should be required and
> what should be optional. Is there anything we don't currently ask for
> which we should?

Categorising the data and getting rid of the unused fields, we get:

1. Data we generate:

* username
* paid - date membership expires (currently blank for life and such or
  Sept. 2007)
* comments - comments for staff, i.e. warnings, extra details for
  societies
* type - membership type, (i.e. student, society, life, alumni)
* uid - system uid, technically this should be the primary key
* lastupdate - when the given entry was last changed
* lastedit - who last changed the entry

2. Data we require from the member (perhaps - please confirm):

* realname
* year - year of study
* email
* id - student ID
* address - postal address
* phone

3. Optional data that the member could provide:

* course - course title
* card_number - swipe card number
* guest_mac  - guestnet mac
* wireless_mac  - unimplemeneted wireless guestnet mac
* rfid_number - rfid card number

If we're looking to tighten up data protection, looking at these three,
it seems logical to allow the user to control the visibility of
categories 2 and 3 and use category 1 only where required. Category 2
could probably be pruned too. I've never used a member's phone number,
address or year of study before, but are they needed by the SU?

But anyhoo, what's the real issue here? Is the data in the db really a
contentious point or are people more worried about data being available
through fingerd or admin tongue slippage or something? Off the top of my
head I don't see anywhere the contents of the members db are being
misused at the moment.

--
Andy Price