-
Notifications
You must be signed in to change notification settings - Fork 30
Open
Milestone
Description
lets give members access to create the sign, if they ask for it, below is how we can split this effort up into multiple prs
create a schema and api like PermissionRequest
lets create a new mongodb schema and api, the schema should have these fields
userId # this should be an index
type # an enum value, which for now can just be LED_SIGN, see audit log schema as an example
deletedAt # a date column, default null- we should make an index on user_id and type so we dont have duplicate entries
- the api we create should create, read and delete records, also an api to return a single record as 200 or 404, we will use this in the next step
- write basic unit tests to validate this behavior, see audit log's api tests an an example
add request button to the led sign page
- if the user visits the page and their role is lower than an officer, query the api to see if they have access,
- if not render a button to ask for access and some clever message like feel free to spam discord to expedite this process
- if the user already requested, dont render the button, but say you requested access to the sign at DATE (use the built in
createdAtfield in mongodb), and the silly message about discord
change ui on led sign page to have a tab, if the user is an officer or admin
this is if the user visits the led sign page and they are an admin role
- make a function like MaybeRenderListOfSignRequests, which calls the api for any active permissionrequests of type LED_SIGN
- render each request as a row, containing user name, email and when the request was made
- they can approve or deny the request in this second tab. the default view is of the first tab which is the led sign ui
- if the request is denied, we delete the record (by setting deletedAt to a non null date)
add a nevermind button on the led sign page for members to undo access
- if the member requested access, they can un-request if they want. this would call the api to delete a record
- we must ensure on the api that the member is only deleting their own request!
change ui on ledsign to allow members to access led sign if they have access
- now that approval/deny works, lets allow the member to mess with the sign if they were given access
make the requests for permission a paginated list
- change the api to be like audit logs, where we return the requests in pages, instead of all at once.
- lets also change the led sign admin page to show the requests in pages, the user ui and audit log ui are great examples of this
separate the permission requests from the led sign page
- lets make a new separate "permission requests" page in the admin view
- move what was on this second tab on the led sign page there
- now, the led sign's second tab will still exist, but clicking it will open the permission requests page in a new tab.
- the permission page should parse filters in the URL like
type=LED_SIGNand use that to call the api, - so when clicking the updated version of the led sign tab, it would open something like https://sce.sjsu.edu/permissions?type=LED_SIGN so we get a filtered view of all led requests.
also if there are no rows, it would be great to render a message like "there are no permission requests, to make one, be a member and visit the led sign page!"
Metadata
Metadata
Assignees
Labels
No labels