Page Comparison

When a user creates an account, the system should require the following information for communication and statistics purposes:

• real name/surname;
• email;
• AEGEE local/contact;
• date of birth (year+exact date)
• nationality;
• field of studies;
• gender.

If a user fails to fill in name, email, exact date of birth, their account can exist but needs to be suspended.

If a user fails to fill in the AEGEE local, year of birth, nationality, field of studies, gender, the account cannot be created. If the user attempts to empty these fields, the change shall not be saved.

• Straight from DPPS
• Saving local might be tricky, because of the architecture. Maybe we can just add their local body/circle membership to their profile and keep track of their local membership history somehow? (up to 5 years)

• Needs CD opinion, or just whatever feels cool 

AEGEE officials (CD,commissioners) do not need insights into nationality, field of studies or gender. AEGEE officials need only see contact information and information that the data subject gave permission for publishing this information internally.

Local boards need only insights into contact 

• Superadmins and certain processing responsibles may need access to ensure functioning of the data and validity of the data.
• Local boards need 

User needs to see different check-boxes when creating or updating their account.

Users should be able to give consent for:

1. To adhere to provisions the statutes of the local and the convention d'adhesion and to agree with the provisions of the data privacy policy of AEGEE-Europe and any system-specific privacy policy (mandatory)
2. The collection of their personal data for the purposes of processing their membership registration (mandatory) 
3. Email preferences
   1. subscribe to ML (announce, aegeenews, aegee,etc) (optional)
   2. agree to receive up to ten commercial messages a year (optional, opt-out)
4. Internal publication of certain types of personal information (optional). Be it
   • Contact details only
   • Contact details and certain personal information
5. Local publication of certain types of personal information (optional, opt-out). Be it
   • Contact details only
   • Contact details and certain personal information
6. Local-defined additional consents (optional)

Partly must have

1. Must
2. Must
3. Good to have 
4. Good to have
5. Nice to have
6. Bonus

• Consent can only be given if a user is logged-in (with their own credentials)
• Consent meta-info needs to be stored for future reference.
• 3b is formally a must-have, but only makes sense if it will actually be implemented by the CD.
• Local consent, especially related to internal publication opt-out, would be a nice extra, but also requires the possibility to shield local members from other local members.

User needs to see different check-boxes when creating or updating their account.

Users should be able to give consent for:

1. Sharing contact and membership information with the organisers (mandatory)
2. Sharing any other information with the organisers? (if any?)(optional)
3. Standard "pictures for promotional purposes consent" (optional, opt-out)
4. Organiser-specified additional consents (optional)

Partly must have

1. must
2. nice?
3. nice
4. bonus

• Consent can only be given if a user is logged-in (with their own credentials)
• Consent meta-info needs to be stored for future reference.
• Not sure what to do with sharing year of birth, nationality, gender. We need a DPC opinion on this matter.

• "Certain personal data may be published online in a system open to AEGEE members only in case the data subject gives its consent."

• We must have a possibility to gather this information. So without a feature for it, there should still be a relatively easy way to compile a machine-readable overview of personal data the OMS has on a person.

• The contract is a must-have. There HAS TO BE A CONTRACT BEFORE a person gets any privileges. Uploading requirement is a nice-to-have.
• Local boards and local officials are except from this requirement for the administration of their own local. Although we could at some point offer them functionality to implement the same, but this depends on the local work-flow.
• Some body, e.g. medcom, dpc, jc, cd, should maybe validate the upload or online agreement within a certain time-frame

• Watch out for phishing risk if we send out automated emails with links in it to login pages.