Main concept

Main concept

Burrito API is a ticket system by its nature. The main idea is to create an open project that could be contributed to by anyone. We aim for the possibility of the appearance of third-party apps created by other students (Telegram bots, mobile apps, desktop apps) that could use Burrito API. And of course, we hope people will use it and it will help them to solve their issues, take answers to questions, and receive wishes and suggestions from students/professors/lecturers/staff.

flowchart RL
gqueue_1_1>Global Queue 1] --> ticket_g_1_1{{ticket}} --> ticket_g_1_2{{ticket}} --> ticket_g_1_3{{ticket}}
gqueue_1_2>Global Queue 2] --> ticket_g_2_1{{ticket}} --> ticket_g_2_2{{ticket}} --> ticket_g_2_3{{ticket}}

faculty1([Faculty 1]) --> queue_1_1>Queue 1] --> ticket_1_1_1{{ticket}} --> ticket_1_1_2{{ticket}} --> ticket_1_1_3{{ticket}}
faculty1([Faculty 1]) --> queue_1_2>Queue 2] --> ticket_1_2_1{{ticket}} --> ticket_1_2_2{{ticket}} --> ticket_1_2_3{{ticket}}
faculty1([Faculty 1]) --> queue_1_3>Queue 3] --> ticket_1_3_1{{ticket}} --> ticket_1_3_2{{ticket}} --> ticket_1_3_3{{ticket}}

faculty2([Faculty 2]) --> queue_2_1>Queue 1] --> ticket_2_1_1{{ticket}} --> ticket_2_1_2{{ticket}} --> ticket_2_1_3{{ticket}}
faculty2([Faculty 2]) --> queue_2_2>Queue 2] --> ticket_2_2_1{{ticket}} --> ticket_2_2_2{{ticket}} --> ticket_2_2_3{{ticket}}
faculty2([Faculty 2]) --> queue_2_3>Queue 3] --> ticket_2_3_1{{ticket}} --> ticket_2_3_2{{ticket}} --> ticket_2_3_3{{ticket}}
faculty2([Faculty 2]) --> queue_2_4>Queue 4] --> ticket_2_4_1{{ticket}} --> ticket_2_4_2{{ticket}} --> ticket_2_4_3{{ticket}}

Loading

The system logic is based on ticket queues (that logically are stacks). There are two types of queues:

• global ones (have no faculties);
• faculty related.

Each faculty has its own set of queues. For example reports, questions, and feature requests. All those types of communication can be interpreted in ticket form which makes it more formal and easy for activity tracking. The purpose of global queues is to handle university global reports or questions.

The next diagram shows a basic ticket lifecycle:

flowchart TD
A([Ticket created, status 'new' not shown for others]) --> B([Primary moderation by faculty/global admins])
B --> C{Does it meet ethical requirements?}
C --> |Yes| D([Status 'open' placed in appropriate queue])
C --> |No| E([Permanently deleted])
D --> F([Assigne takes ticket])
F --> G([Assignee works on ticket])
G --> H([Assignee gives a feedback])
H --> J{Is ticket resolved?}
J --> |Yes| I([Status 'closed'])
J --> |No| K([Status 'waiting', waiting for an answer from requestor])
K --> L([Received an answer from requestor])
L --> M([Status 'open']) --> G

Loading