Addition of announcement page for admin

[Owaiseimdad]

Is your feature request related to a problem? Please describe. No, its a new introduction of a feature in order to manage the announcements. So, lets say the dev team needs to announce something to the users right now we have no checkmate.com/announcements which might give information about updates and more.

Describe the solution you'd like

1. Introduction of a new page called announcements page which is only visible to admin users, they can create or delete any announcements.
2. Public url for end users to see the announcements

Describe alternatives you've considered No alternatives for now, for example, if there is something extra which can be done which is if they subscribe to the announcements then they might receive an email as an update, just a thought.

[Owaiseimdad]

cc: @gorkemcetin @ajhollid

[gorkem-bwl]

Let's try to get this in 2.1 if possible.

[Owaiseimdad]

Title: Feature: Implement General Announcements System

Description:

This feature introduces a system for administrators to create and manage general announcements that can be displayed to users. Unlike status page specific incidents, these announcements are intended for broader communication (e.g., new features, global maintenance, general updates) and are not tied to a single status page.

Requirements:

Admin User Interface (UI - Admin):

1. Announcements Management Page:
   • Create a dedicated "Announcements" section within the admin dashboard.
   • The initial view of this page should display a list of previously created general announcements.
   • (Decision Needed: What details to show in the list? e.g., Title, Created At, part of Message?)
2. Create Announcement Button:
   • The Announcements Management Page should feature a "Create Announcement" button.
3. Create Announcement Form/Page:
   • Clicking the "Create" button should lead to a form (a new page).
   • The form must contain fields for:
     • Title: (Text input, required)
     • Description: (Text area, required)
   • The creation timestamp should be recorded automatically by the backend when the announcement is saved.

Public User Interface (UI - User):

1. Public Accessibility:
   • There needs to be a way for end-users to view these general announcements.
   • (Decision Needed: How should users access this? A dedicated public URL? A section added to all existing public status pages?) Preferably, the data endpoint should be public.
2. Display & Order:
   • Display the list of general announcements chronologically.
   • The newest announcement should appear first (at the top), and the oldest announcement should appear last (at the bottom). (Note: This is the reverse of typical feeds)

Backend API:

1. Create Announcement Endpoint:
   • Implement POST /api/v1/announcements.
   • Requires admin authentication (verifyJWT middleware).
   • Accepts a JSON body with title (string, required) and message (string, required).
   • Saves the new announcement to the database, automatically adding createdAt and updatedAt timestamps (and potentially userId from auth).
   • Returns the created announcement object or a success status (e.g., 201 Created).
2. Get Announcements Endpoint:
   • Implement GET /api/v1/announcements.
   • Should be publicly accessible.
   • Retrieves all general announcement documents from the database.
   • Supports pagination via query parameters (e.g., ?limit=20&page=1).
   • Returns a JSON array of announcement objects, sorted by createdAt in ascending order (oldest first).
   • Returns status 200 OK.

Acceptance Criteria:

• An admin user can navigate to a new "Announcements" section in the dashboard.
• The admin can view a list of previously created general announcements.
• The admin can click a button to access the "Create Announcement" form.
• The admin can successfully submit the form with a title and description.
• The newly created announcement appears in the list on the admin management page.
• The POST /api/v1/announcements endpoint successfully creates records and requires authentication.
• The GET /api/v1/announcements endpoint is publicly accessible and returns a list of announcements.
• The list returned by GET /api/v1/announcements is sorted with the oldest announcement first.
• The GET endpoint correctly implements pagination (limit, page).

Open Questions:

• Confirm the strategy for the public display of these general announcements (Dedicated URL? Section on existing pages?).
• Confirm default/max values for pagination on the GET endpoint.
• Confirm specific fields and layout for the admin announcement list view.
• I am also thinking on "delete" feature for the admin to remove any mistakenly added announcements.

cc: @gorkem-bwl @ajhollid

[Owaiseimdad]

@gorkem-bwl , can't promise complete feature by 2.1 but the backend will be done by 2.1 for sure.

[Owaiseimdad]

I performed a POC on the same team,

Please let me know what your thoughts are.

https://github.com/user-attachments/assets/367e63e8-7184-4339-bf1e-6e409548bc4c

cc: @ajhollid @gorkem-bwl

[gorkem-bwl]

I performed a POC on the same team,

Please let me know what your thoughts are.

This PoC looks good. You are on the right path.

As per your questions above I'll answer them promptly soon so we can be on the same page 99%.

[gorkem-bwl]

As per your questions:

1. What's to be included: The announcement title, contents and date of the announcement. Also include a pretty date next to the actual date (e.g "3 days ago").
2. How should users access this? A dedicated public URL? A section added to all existing public status pages? Each announcement would be tied to one or more status pages. If there is one announcement, it's always under >=1 status page(s).
3. Confirm the strategy for the public display of these general announcements: This would be a section on an existing status page. Ideally/preferably as a tabbed bar item. In this case we have 2 tabs - Status page and Announcements (IF there is a corresponding announcement in that status page).
4. Confirm default/max values for pagination on the GET endpoint. By default it can be 5, but can be configurable with a drop down.
5. Confirm specific fields and layout for the admin announcement list view. The admin can see them as a list, but the public page will include all announcements one after another under "Announcements" tab. There won't be a list, but all announcements in order, and paginated.
6. I am also thinking on "delete" feature for the admin to remove any mistakenly added announcements. Yes, probably via an action button just like what we have in monitors. It would include Edit and Delete.

[ajhollid]

@Owaiseimdad I think in general this looks good. I'll leave the UI/UX component of review to @gorkem-bwl , my thoughts from a technical point of view are

1. There is a relationship between stastus pages and announcements, what exactly is it? There should be a link on status pages to the announcement page associated with that status page?

2. There should be GET, POST, PUT (if editing announcements is allowed), and DELETE endpoints for Announcements

I think other than that there's not much to this, it is a pretty straight forward feature.

On to administration, I'm going to put this in bold and large since it is often ignored,

Please make many very small pull requests instead of fewer large ones

This is a simple feature, but it will require a non-trivial amount of code to implement. It is not going to be reviewed in a reasonable time, if at all, if it is submitted in large chunks.

I suggest doing this in the following order, starting with backend

Backend

1. Add controllers and routes 1a. Add POST 1b. Add GET 1c. Add PUT 1d. Add DELETE

2. Add DB methods 2a. POST 2b. GET 2c. PUT 2d. DELETE

Frontend Make PRs per component as appropriate. Make PRs per operation as required

It is tempting to implement the whole FE all at once, but this feature is singificant enough that it should be done in small, manageable chunks.

In my experience managing this project so far PRs are often submitted that are not of a reasonable size, so with that said I will just close PRs that I feel are not reasonably reviewable and request a new, more appropriately sized PR be submitted.

That's all the boilerplate out of the way 😂 This looks like an exciting feature and I look forward to seeing what you come up with!

[gorkem-bwl]

I'll leave the UI/UX component of review to @gorkem-bwl , my thoughts from a technical point of view are

For now, since it's a PoC, we are good. When @Owaiseimdad starts using the components and starts finalizing the design, I can weigh in.

[Br0wnHammer]

@Owaiseimdad The PoC looks solid. What if instead of a table structure we used cards as announcements on the page?

[Owaiseimdad]

Thats the plan @Br0wnHammer , no extra ui code, will reuse as much as possible.

[gorkem-bwl]

I'll go ahead and move this to 3.0, as it's not a small feat to add to 2.1 :)