Skip to content

allow members to mess with the sign #1953

@evanugarte

Description

@evanugarte

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 createdAt field 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_SIGN and 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
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions