Brontosaurus events: Organizator roles

[mrkvon]

As we discussed, there are two types of Organizator permission groups:

• org (users with ORG role)
• org-team (users (or ORGs?) who are main organizer of event, or member of organizer team)

In this issue we clarify which actions can be done by org and which can be done by org-team

Important! Currently, this issue is a draft and we need to discuss and confirm the details with project owner (Brontosaurus)

Org team

In general, any actions that update or delete events and change their relationships + create and edit event participants

• read event
• update event
• delete event?
• read event attendees
• add event attendee (we need to discuss security of that)
• remove event attendee
• create an event attendee (participant who doesn't exist, yet)
• edit data of event attendees (we need to discuss security of that, related to "add event attendee")

(this list may not be complete)

Org

• create event (the person creating it should be able to edit the event afterwards, e.g. become part of org team of the event)
• anything not directly related to events
  • search users (by query string - find users whose name, surname, nickname include the query string)
  • list administrative units (or everybody can?)
  • list event types (or everybody can?)

Unclear to me

• locations?

[timthelion]

When you say "read event attendees" what information about the attendees to you need? Name? Email? Address?

[timthelion]

What kind of user data do event organizers need to be able to edit?

[timthelion]

Everything is done except the endpoint to allow event organizers to edit user info. I haven't made it so that event organizers can't sign up users without birthdate. I'd rather gate the sensitive user data at the endpoint where it is exposed. As it stands, since anyone can sign anyone else up for event only knowing their email, it would be security theater to then require DOB to sign up a user in the admin.

I'll probably be able to finish up that last endpoint tomorrow.

[timthelion]

Done: https://github.com/auto-mat/klub/commit/2bb1ca0c442682e275c55c89583f822e8e45e9ad

[mrkvon]

@timthelion Thanks, and sorry for not being responsive.

When you say "read event attendees" what information about the attendees to you need? Name? Email? Address?

I think it's defined in https://docs.google.com/document/d/1w_XZXEeqNtGgFFjjUYhk7bzy-0Goiw03TDaYUimKYuk

U usera ke kterému má přístup může zobrazit: jeho osobní informace a fotku typ preferované akce a organizátorskou roli z Rozcestníku kvalifikace - (ty budou v BISu přidány k userovi jako interakce) ocenění - Březový lístek - (ten bude přidán v BISu k userovi jako interakce)
může vidět jakého článku je (byl) členem jestli má členskou průkazku (bude v BISu v budoucnu)

Nemá oprávnění: zobrazit ostatní akce, na kterých user byl, ale které daný organizátor neorganizoval (není to tak prioritní) zobrazit dary daného usera (ani dary pro ZČ) zobrazit jestli user zaplatil členský příspěvek (což stejně asi bude řešeno tak, že je členem HB = zaplatil členský příspěvek)

What kind of user data do event organizers need to be able to edit?

I don't know an answer to that. Perhaps people from Brontosaurus can answer that? (I don't know if they have github username)

I'd rather gate the sensitive user data at the endpoint where it is exposed. As it stands, since anyone can sign anyone else up for event only knowing their email, it would be security theater to then require DOB to sign up a user in the admin.

Good point. But then, perhaps the person joining an event should provide a correct name and birthdate, too? When it comes to date of birth and editing users, we should get a feedback on that, to properly understand when and why should organizers be able to edit user data. I don't know if they need to always have users' birthdays at hand when editing.

@timthelion Please let's get a feedback on this issue from the project owners (Brontosaurus) first before further doing anything with it. My opinion is not binding.