Users and Events are the most important part of FOSSASIA‘s Open Event Server. Through the advent and upgradation of the project, the way of implementing user event roles has gone through a lot many changes. When the open event organizer server was first decoupled to serve as an API server, the user event roles like all other models was decided to be served as a separate API to provide a data layer above the database for making changes in the entries. Whenever a new role invite was accepted, a POST request was made to the User Events Roles table to insert the new entry. Whenever there was a change in the role of an user for a particular event, a PATCH request was made. Permissions were made such that a user could insert only his/her user id and not someone else’s entry.
def before_create_object(self, data, view_kwargs):
"""
method to create object before post
:param data:
:param view_kwargs:
:return:
"""
if view_kwargs.get('event_id'):
event = safe_query(self, Event, 'id', view_kwargs['event_id'], 'event_id')
data['event_id'] = event.id
elif view_kwargs.get('event_identifier'):
event = safe_query(self, Event, 'identifier', view_kwargs['event_identifier'], 'event_identifier')
data['event_id'] = event.id
email = safe_query(self, User, 'id', data['user'], 'user_id').email
invite = self.session.query(RoleInvite).filter_by(email=email).filter_by(role_id=data['role'])\
.filter_by(event_id=data['event_id']).one_or_none()
if not invite:
raise ObjectNotFound({'parameter': 'invite'}, "Object: not found")
def after_create_object(self, obj, data, view_kwargs):
"""
method to create object after post
:param data:
:param view_kwargs:
:return:
"""
email = safe_query(self, User, 'id', data['user'], 'user_id').email
invite = self.session.query(RoleInvite).filter_by(email=email).filter_by(role_id=data['role'])\
.filter_by(event_id=data['event_id']).one_or_none()
if invite:
invite.status = "accepted"
save_to_db(invite)
else:
raise ObjectNotFound({'parameter': 'invite'}, "Object: not found")
Initially what we did was when a POST request was sent to the User Event Roles API endpoint, we would first check whether a role invite from the organizer exists for that particular combination of user, event and role. If it existed, only then we would make an entry to the database. Else we would raise an “Object: not found” error. After the entry was made in the database, we would update the role_invites table to change the status for the role_invite.
Later it was decided that we need not make a separate API endpoint. Since API endpoints are all user accessible and may cause some problem with permissions, it was decided that the user event roles would be handled entirely through the model instead of a separate API. Also, the workflow wasn’t very clear for an user. So we decided on a workflow where the role_invites table is first updated with the particular status and after the update has been made, we make an entry to the user_event_roles table with the data that we get from the role_invites table.
When a role invite is accepted, sqlalchemy add() and commit() is used to insert a new entry into the table. When a role is changed for a particular user, we make a query, update the values and save it back into the table. So the entire process is handled in the data layer level rather than the API level.
The code implementation is as follows:
def before_update_object(self, role_invite, data, view_kwargs):
"""
Method to edit object
:param role_invite:
:param data:
:param view_kwargs:
:return:
"""
user = User.query.filter_by(email=role_invite.email).first()
if user:
if not has_access('is_user_itself', id=user.id):
raise UnprocessableEntity({'source': ''}, "Only users can edit their own status")
if not user and not has_access('is_organizer', event_id=role_invite.event_id):
raise UnprocessableEntity({'source': ''}, "User not registered")
if not has_access('is_organizer', event_id=role_invite.event_id) and (len(data.keys())>1 or 'status' not in data):
raise UnprocessableEntity({'source': ''}, "You can only change your status")
def after_update_object(self, role_invite, data, view_kwargs):
user = User.query.filter_by(email=role_invite.email).first()
if 'status' in data and data['status'] == 'accepted':
role = Role.query.filter_by(name=role_invite.role_name).first()
event = Event.query.filter_by(id=role_invite.event_id).first()
uer = UsersEventsRoles.query.filter_by(user=user).filter_by(event=event).filter_by(role=role).first()
if not uer:
uer = UsersEventsRoles(user, event, role)
save_to_db(uer, 'Role Invite accepted')
In the above code, there are two main functions – before_update_object which gets executed before the entry in the role_invites table is updated, and after_update_object which gets executed after.
In the before_update_object, we verify that the user is accepting or rejecting his own role invite and not someone else’s role invite. Also, we ensure that the user is allowed to only update the status of the role invite and not any other sensitive data like the role_name or email. If the user tried to edit any other field except status, then an error is shown to him/her. However if the user has organizer access, then he/she can edit the other fields of the role_invites table as well. The has_access() helper permission function helps us ensure the permission checks.
In the after_update_object we make the entry to the user event roles table. In the after_update_object from the role_invite parameter we can get the exact values of the newly updated row in the table. We use the data of this role invite to find the user, event and role associated with this role. Then we create a UsersEventsRoles object with user, event and role as parameters for the constructor. Then we use save_to_db helper function to save the new entry to the database. The save_to_db function uses the session.add() and session.commit() functions of flask-sqlalchemy to add the new entry directly to the database.
Thus, we maintain the flow of the user event roles relationship. All the database entries and operation related to users-events-roles table remains encapsulated from the client user so that they can use the various API features without thinking about the complications of the implementations.
Reference:
