Documented relago-support #7

New issue

Open

opened 2026-05-21 07:47:19 +00:00 by xfeusw · 0 comments

xfeusw commented

2026-05-21 07:47:19 +00:00

Member

Models in relago-support:

Report
Ticket
Supporter (admin)
Comment

Report:

Field	Relationship
Ticket	One-to-one

Supporter (admin):

Field	Relationship (optional)
Ticket	One-to-many

Comment:

Field	Relationship (optional)
author	Many-to-one
post	Many-to-one

Status

Status	Why?	When?
Open	To make available for supporters	When report creates ticket
In progress	To make sure it's in progress	When supporter accepts ticket and works on it
Closed	To close ticket	When supporter completes ticket
Pending	To leave it for future	When supporter have other tickets/tasks in higher priorities

Endpoints

We gonna use REST API for designing our endpoints

Ticket

Endpoints	Method	Why?
/api/tickets/	Get	To get all tickets
/api/tickets/:id/	Get	To get ticket with specific id
/api/tickets/	Post	To create new ticket
/api/tickets/:id/	Patch	To change status of ticket

Comments

Endpoints	Method	Why?
/api/comments/	Get	To get all comments
/api/tickets/:ticket_id/comments/	Get	To get all comments of ticket_id
/api/tickets/:ticket_id/comments/	Post	To create comment for ticket_id
/api/tickets/:ticket_id/comments/:id/	Get	To get exact comment by id from ticket_id
/api/tickets/:ticket_id/comments/:id/	Patch	To edit comment by id from ticket_id

Flow:

We receive report and create ticket. Its status will be Open. Then we start to work in ticket and the status will be In progress. If we find solution, we close it give it Closed. If we can't find solution, we gonna give Pending and will be able to reassign with status Reassigned.

FAQ

Why are they separated? We need separate logic into details. So we have report which we received from user and we have ticket which we created because of report
How supporters will be assigned to tickets?
When new ticket creates, our system will notify maintainers via email. Then maintainers will assign supporters for ticket and they will work on it

Statuses inspired from: link
Patching ticket should be in exact forms for security reasons.
In what cases, we could edit tickets?
- To change status
- To assign new supporter
- To change supporter
Observing all of these, I prefer to 5 forms of patching ticket via API. The form can be given in JSON or as parameter in url. The forms:
- To change status to In progress and assign new supporter
- To change status to Closed
- To change status to Pending
- To change status to Reassigned (with option to change supporter)
- To change supporter himself

Authentication

it will be implemented via KeyCloak in Uzinfocom OSS due to our team works as supporters at the beginning of the project. Later, we gonna implement roles too (This section will be filled later)

Etc, drafts

Mute name is rough, so we gonna use Pending instead. It means the task will be in wait mode. We dropped the idea of implementing priorities of pending status in deep side of mind
When we set status of ticket to Pending, later someone will work on this ticket. In order to not to start all again completely, we need to implement comments for each ticket. !!! Don't forget to add /create fields in main description
Multiple supporters should be able to work in one ticket

## Models in relago-support: - Report - Ticket - Supporter (admin) - Comment ## Report: |Field|Relationship| |-----|-----------------------| |Ticket| One-to-one| ## Supporter (admin): |Field|Relationship (optional)| |-----|-----------------------| |Ticket| One-to-many| ## Comment: |Field|Relationship (optional)| |-----|-----------------------| |author|Many-to-one| |post|Many-to-one| ### Status |Status|Why?|When?| |------|----|-----| |Open|To make available for supporters|When report creates ticket| |In progress|To make sure it's in progress|When supporter accepts ticket and works on it| |Closed|To close ticket|When supporter completes ticket| |Pending|To leave it for future|When supporter have other tickets/tasks in higher priorities|  ## Endpoints We gonna use REST API for designing our endpoints ### Ticket |Endpoints|Method|Why?| |--------|-----|------| |/api/tickets/|Get|To get all tickets| |/api/tickets/:id/|Get|To get ticket with specific id| |/api/tickets/|Post|To create new ticket| |/api/tickets/:id/|Patch|To change status of ticket| ### Comments |Endpoints|Method|Why?| |--------|-----|------| |/api/comments/|Get|To get all comments| |/api/tickets/:ticket_id/comments/|Get|To get all comments of ticket_id| |/api/tickets/:ticket_id/comments/|Post|To create comment for ticket_id| |/api/tickets/:ticket_id/comments/:id/|Get|To get exact comment by id from ticket_id| |/api/tickets/:ticket_id/comments/:id/|Patch|To edit comment by id from ticket_id| ## Flow: We receive report and create ticket. Its status will be Open. Then we start to work in ticket and the status will be In progress. If we find solution, we close it give it Closed. If we can't find solution, we gonna give Pending and will be able to reassign with status Reassigned. ## FAQ + Why are they separated? We need separate logic into details. So we have report which we received from user and we have ticket which we created because of report + How supporters will be assigned to tickets? When new ticket creates, our system will notify **maintainers** via email. Then maintainers will assign supporters for ticket and they will work on it * Statuses inspired from: [link](https://dataeq.com/knowledge-base/what-do-the-different-ticket-statuses-mean) * Patching ticket should be in exact forms for security reasons. * In what cases, we could edit tickets? - To change status - To assign new supporter - To change supporter * Observing all of these, I prefer to 5 forms of patching ticket via API. The form can be given in JSON or as parameter in url. The forms: - To change status to In progress and assign new supporter - To change status to Closed - To change status to Pending - To change status to Reassigned (with option to change supporter) - To change supporter himself # Authentication it will be implemented via **KeyCloak** in **Uzinfocom OSS** due to our team works as supporters at the beginning of the project. Later, we gonna implement roles too (This section will be filled later) ## Etc, drafts * _Mute name is rough, so we gonna use Pending instead. It means the task will be in wait mode. We dropped the idea of implementing priorities of pending status in deep side of mind_ * _When we set status of ticket to Pending, later someone will work on this ticket. In order to not to start all again completely, we need to implement comments for each ticket. **!!! Don't forget to add /create fields in main description**_ * _Multiple supporters should be able to work in one ticket_