Together Admin Dashboard Technical Specification

[InstincDev]

Summary

The Together admin dashboard allows authorized users to manage and monitor the application's backend. It should provide a streamlined interface for managing events and user accounts.

Scope

• The Together User schema must contain an "admin" role - boolean.
• The Together User schema must contain a "notes" role - string.
• The Together Event schema must contain a "verification" role - approved, pending, rejected.
• The Together Event schema must include a "notes" role - string.
• The dashboard should visually display the Event objects.
• The dashboard should contain a Search/Filter option to see approved, pending, and rejected Event objects.
• The dashboard should have verification routes that update the event object from pending to approved/rejected.
• The dashboard should have Buttons to control verification routes.
• The dashboard should display Recurring Events as a group.
• Only the approved events should be displayed on the Together calendar.

Data Model

No response

User Stories

• Users login into the main Together login page.
• After logging in users with the admin role button are able to see the dashboard button.
• The dashboard button leads Admin users to the dashboard homepage
• On the dashboard homepage Admin users can see an overview of active and pending events, as well as filter/search events and user data.
• The Event Management section allows Admin users to validate and delete events - individually and batched.
• The User Account management section allows Admin users to view, edit, and delete user accounts, as well as restrict users' create event access.
• If an event and or user is restricted only Admin users can view, edit, and delete the note detailing the reason for the restriction.
• Admin user confirms all restrictions and deletions, event remains in the DB but doesn't appear on the calendar.
• If the Admin user approves an event, the event becomes viewable in the calendar.

Implementation Details

• The application should use client-side validation to ensure that user input is valid before submitting it to the server.
• The application should use server-side validation to ensure that all user input is properly sanitized and validated before being stored in the database.
• The application should be modular and maintainable, with separate files for HTML, CSS, and JavaScript.

APIs

No response

Security/Privacy

Admin dashboard needs to be accessible by only verified members of the Together project and 100Devs Mods.

Testing

• The application should be tested for functionality and security.
• The application should be tested using automated testing tools such as Jest or Cypress.?.
• The application should be tested manually by a human tester to ensure that all features are working as expected.

Open Questions

No response

Deployment

As we're deploying major changes in the Event and User schemas to an already functioning application and DB any changes to production should be carefully considered and timed.

[Caleb-Cohen]

Awesome! Great work.

The Together User schema must contain an "admin" role - boolean.
The Together User schema must contain a "notes" role - string.
The Together Event schema must contain a "verification" role - approved, pending, rejected.
The Together Event schema must include a "notes" role - string.
The application must support multiple user roles with different levels of access.?.

I'm not sold on the notes and multiple roles at this moment. Maybe in the future. What are you thoughts on adding the items below to the scope?

• Visualizing event objects in the dashboard
• Filter option to see approved, pending, rejected event objects
• Routes to update the event object from pending to approved/rejected
• Buttons for the previous routes
• Grouping of event objects that are recurring events
• Visualising only approved events in the calendar

The Event Management section allows Admin users to validate, create, edit, and delete events - individually and batched.

I prefer to create and edit in a different tech spec.

How do you want data to pass from the server back to the client within the admin panel?

[InstincDev]

I'm not sold on the notes and multiple roles at this moment.

I think that having notes, or some type of documentation, is important in case there is an issue as to why an event was rejected. As for the multiple roles, it was just a thought and can be considered at a later date.

[InstincDev]

What are you thoughts on adding the items below to the scope?

• Visualizing event objects in the dashboard
  * Filter option to see approved, pending, rejected event objects
  * Routes to update the event object from pending to approved/rejected
  * Buttons for the previous routes
  * Grouping of event objects that are recurring events
  * Visualizing only approved events in the calendar

Most of this is addressed under the User Stories section. If this is the incorrect location Sorry.😅 I will add them to the Scope section as well.

I prefer to create and edit in a different tech spec.

I will remove this portion

[InstincDev]

How do you want data to pass from the server back to the client within the admin panel?

I am not sure how to answer that. From what I understand, data will pass from server to client in the same way that it is passed with the calendar.

[Caleb-Cohen]

I think that having notes, or some type of documentation, is important in case there is an issue as to why an event was rejected. As for the multiple roles

Have we had any events that have needed such treatment as of yet?

Most of this is addressed under the User Stories section.

The scope should encompass all the main points. Each subsequent section is just a more detailed explanation of something within the scope.

same way that it is passed with the calendar.

Works for me!

Some follow-up to consider for implementation details will be how will we make the changes to the user model in Mongo.

I'd like to post the issues here before moving to the issues tab. How would you like to proceed? I have availability pretty open availability to work on this through Monday.

[Caleb-Cohen]

---

Issue Name: Converting React Router to Together
Related Issues

Project: Admin Dashboard
Depends on: N/A

Description
Convert routing within client app.js to utilize react-router
Create LandingPage.js in client/pages

Acceptance Criteria
Able to route between homepage, calendar, back to homepage and to admin dashboard
Tests setup to confirm

---

Issue Name: Create a button to access the admin Dashboard
Related Issues

Project: Admin Dashboard
Depends on: Converting React Router to Together

Description
Create a button on the homepage that will access the admin dashboard
Renders admin dashboard

Acceptance Criteria
Button exists

---

Issue Name: Add an API endpoint that will return all events for admin Dashboard
Related Issues

Project: Admin Dashboard
Depends on: N/A

Description
Add getEventsForAdmin method in the events.js controller that will return all events
Acceptance Criteria
API endpoint returns all events
Passes test

---

Issue Name: Visualize all events returned from getEventsForAdmin
Related Issues

Project: Admin Dashboard
Depends on: N/A

Description
Add getEventsForAdmin to dataService
Visualize all object returned in AdminDashboard.js
Each object should have event name, description, and author
Acceptance Criteria
Visualizes all events
Testing to ensure it’s visualized

---

Issue Name: Update Events model to contain a status field
Related Issues

Project: Admin Dashboard
Depends on: N/A

Description
Add status to Events.js model
status should be a string with default of “pending”
Required: true
Create a function to update all current event objects to have status field. Set as active.

Acceptance Criteria
Test submitting and check event objects

---

Issue Name: Notifiy the user that the event has been added to pending instead of confirming the event has been added.
Related Issues

Project: Admin Dashboard
Depends on: Update Events model to contain a status field

Description
Edit the event form confirmation message to instead say the event has been pending and will be reviewed by staff before being added to the calendar.

Acceptance Criteria
Update E2E test to match new behavior.

---

Issue Name: Change API endpoint getEventsForAdmin to only show pending events.
Related Issues

Project: Admin Dashboard
Depends on: Update Event Model to contain status field

Description
Update getEventsForAdmin method in the events.js controller such that it will only return all events with a status of pending

Acceptance Criteria
Test that each returned event has the status of pending

---

Issue Name: Create a method for approving admin events
Related Issues

Project: Admin Dashboard
Depends on: Update Event Model to contain status field

Description
Create a method in the event.js controller called approveEvents
Method will change specific event objects status to approved
Create post route in events.js
Create axios request

Acceptance Criteria
Test updated event object has been changed from pending to approved

---

Issue Name: Create a method to Deny admin events
Related Issues

Project: Admin Dashboard
Depends on: Update Event Model to contain status field

Description
Create a method in the events.js controller called denyEvent
Method will change specific event objects status to denied
Create post route in events.js
Create axios request
Acceptance Criteria
Test updated event object has been changed from pending to denied
Event object should remain in the database

---

Issue Name: Visualize all single events objects, but group recurring events into one event object
Related Issues

Project: Admin Dashboard
Depends on: Visualize all events returned from getEventsForAdmin

Description
If event is recurring only visualize one object
Use groupID to detect and group recurring events

Acceptance Criteria
Visualizes all single events
Testing to accompany

---

Issue Name: Create a filter that allows event objects to be viewed by status code
Related Issues

Project: Admin Dashboard
Depends on: Visualize all events returned from getEventsForAdmin

Description
Button that allows filtering to see pending, denied, or allowed events
Either using mongoDB queries or React state and filter

Acceptance Criteria
Testing to accompany

---

Issue Name: Add approve/deny events button to each visualized event on the dashboard
Related Issues

Project: Admin Dashboard
Depends on: Visualize all events returned from getEventsForAdmin, Create a method for approving admin events, Create a method to Deny admin events

Description
Button attached to each event object
Updates status within DB

Acceptance Criteria
Testing to accompany

---

[InstincDev]

Overall questions -

• How specific should each issue be in explaining what needs to be done?
• Should the issues include a reference as to whether it is for the Server/Client side or is this only seen on the labels?
• Are none of these issues related to each other or other issues?
• How should overall formatting and capitalization (admin or Admin Dashboard) be done?

Issue Name: Converting React Router to Together

• Not sure what setting up the React Router entails. Should be its own issue?
• Create LandingPage.js is unclear, did you mean the DashboardPage.js?

Issue Name: Create a button to access the admin Dashboard

• Should this issue also mention a button on the Admin Dashboard page that links back to the landing/calendar pages?
• Should this issue include adding a link to the Hamburger Nav?

Issue Name: Visualize all events returned from getEventsForAdmin

• Does this issue not depend on the issue 'Add an API endpoint that will return admin dashboard' ?
• Should adding to data service be its own issue since it is moving from the server side to the client side?
• "Visualizes all events" as Acceptance Criteria is a bit vague. I think this sentence better explains what should be expected as Acceptance Criteria - 'Each object should have an event name, description, and author.'

Issue Name: Update Events model to contain a status field

• Should this issue be split into 'Updating the Events model' and 'Updating all the current event objects'?

Issue Name: Create a method for approving admin events

• Should this issue update All Recurring events even though only one is displayed - per 'Visualize all single events objects, but group recurring events into one event object'?
• I think the controller should be called approveEvent

Issue Name: Create a method to Deny admin events

• Should this issue update All Recurring events even though only one is displayed - per 'Visualize all single events objects, but group recurring events into one event object'?

Issue Name: Visualize all single events objects, but group recurring events into one event object

• What does 'Testing to accompany' mean?

Issue Name: Create a filter that allows event objects to be viewed by status code

• Should this be a dropdown instead of a button?

[Caleb-Cohen]

How specific should each issue be in explaining what needs to be done?

As specific as reasonably possible. Someone with little knowledge of the application should have a rough idea of what they need to do.

Should the issues include a reference as to whether it is for the Server/Client side or is this only seen on the labels?

I'm not sure I understand the question, but some reference should be made if relevant to solving the issue.

Are none of these issues related to each other or other issues?
Sorry for the formatting makes it unclear, related issue is a header. It references the project board and directly dependent on issues below.

How should overall formatting and capitalization (admin or Admin Dashboard) be done?

I haven't really thought about it, do you have a preference?

Not sure what setting up the React Router entails. Should be its own issue?

From what @MatthewBozin said it sounds pretty simple and quick, but I agree if it's a more convoluted process. I will notate to look into it.

Create LandingPage.js is unclear, did you mean the DashboardPage.js?

Good catch, thank you. I adjusted it to AdminDashboard.js instead.

Should this issue also mention a button on the Admin Dashboard page that links back to the landing/calendar pages?

Good catch, I've updated the ticket.

Should this issue include adding a link to the Hamburger Nav?

Yes, it can.

Does this issue not depend on the issue 'Add an API endpoint that will return admin dashboard' ?

Yes, updated.

Should adding to data service be its own issue since it is moving from the server side to the client side?

No, while we should have the goal to make issues digestible and concise crossing the client/server barrier doesn't not automatically require a split issue. It's really good to keep that in mind though. Besides, dataService is more of a middleman between the client and server.

"Visualizes all events" as Acceptance Criteria is a bit vague. I think this sentence better explains what should be expected as Acceptance Criteria - 'Each object should have an event name, description, and author.'

Good advice, thank you!

Should this issue be split into 'Updating the Events model' and 'Updating all the current event objects'?

How do we test if the model has been updated properly if we can test the current event objects?

Should this issue update All Recurring events even though only one is displayed - per 'Visualize all single events objects, but group recurring events into one event object'?

No. I think that will complicate this issue to much. I'll add an issue after Visualize all single events objects, but group recurring events into one event object

I think the controller should be called approveEvent

Agreed, updated.

Should this issue update All Recurring events even though only one is displayed - per 'Visualize all single events objects, but group recurring events into one event object'?

No, see above.

What does 'Testing to accompany' mean?

That's just me just saying create tests that show the functionality.

Should this be a dropdown instead of a button?

Agreed.

Phew, thanks for taking the time to write these up!

[InstincDev]

Should the issues include a reference as to whether it is for the Server/Client side or is this only seen on the labels?

- I'm not sure I understand the question, but some reference should be made if relevant to solving the issue.

I know that when created, each issue can/will have a server-side or client-side label. Most of the issues for the Admin Dashboard are client-side. However, a few key ones are not. It is not mentioned in the issues whether or not they pertain to the Server/ Client side. Without the label, it took me some time to find files.

How should overall formatting and capitalization (admin or Admin Dashboard) be done?

-I haven't really thought about it, do you have a preference?

I think the component should be called AdminDashboard and referred to as such. But more importantly, it should follow the naming conventions found in the rest of the code.

Should this issue be split into 'Updating the Events model' and 'Updating all the current event objects'?

-How do we test if the model has been updated properly if we can test the current event objects?

If I understand it correctly, changing the Events model will create a breaking change for the current events in the calendar. Meaning that the current events in the database will have to be updated to match the model. This should not prevent the testing of new dummy data within the updated model. The question is, do we want one issue to update and test the model AND update the database?

[soph-em]

I've had a quick read through, I had a couple of just initial thoughts, but not 100% sure if they're within scope of this tech spec or might have missed info somewhere.

• the user stories says that all users with an admin role will be notified of any event creation, I don't think I can see a issue that contains this
• is it going to be made clear to a user at the point of creating an event that it will be reviewed, to prevent multiple submissions/database entries out of confusion when the event is not immediately visible?
• will the event creator be informed in any way if the event is approved or denied or would they just have to check the calendar intermittently?

[InstincDev]

Thank you for the review @soph-em

the user stories says that all users with an admin role will be notified of any event creation, I don't think I can see a issue that contains this

is it going to be made clear to a user at the point of creating an event that it will be reviewed, to prevent multiple submissions/database entries out of confusion when the event is not immediately visible?

will the event creator be informed in any way if the event is approved or denied or would they just have to check the calendar intermittently?

These are all good points. I think that notifications are important, but from what I am understanding, should be dealt with in another tech spec. @Caleb-Cohen is this correct?

[Caleb-Cohen]

Let's pull the notification out of this tech spec. I'd love to put the notification into the Discord bot, which is outside the scope if we had some other form of notification like email, then we could set up an issue here.

is it going to be made clear to a user at the point of creating an event that it will be reviewed, to prevent multiple submissions/database entries out of confusion when the event is not immediately visible?

Yes good point, I'll make an issue.

will the event creator be informed in any way if the event is approved or denied or would they just have to check the calendar intermittently?

I don't think we'd have that in this tech spec, as stated earlier I'd like to get the notifs running through the discord bot. I am open to some other form of notification that we could setup earlier, but I don't think it's necessary.