Tickets

[danieljames-dj]

Tickets is a table with following columns:

id: integer
type: string (will be explained different types later below)
metadata: table (will be explained along with ticket types)
initiator: string (user_id or usergroup_id)
stakeholders: Array of string (user_id or usergroup_id)
status: string (open, closed)
action_required_by: string (WRT, Delegate, etc)
logs: Array of TicketLog

Advantages of tickets

1. Reduced workload for WRT
   Different requests that WRT is handling via email can be moved to tickets and it will save plenty of time which WRT uses to write emails. Some requests that have the potential to be moved are:

• Edit person requests
• Edit result requests
• General comment for WRT
• Avatar change request
• Results import

2. Easy request handling for other teams/delegates
   I didn’t say these as ‘reduced workload’ because I don’t exactly know how easier it will be and only those teams can say if this will be better for them. Some cases that come in my mind are:

• [WCT] General comments from public
• [WCT] Media approvals
• [WCAT] Competition announcements
• [WFC] Dues payment
• [WRC] Discussions on report incidents assigned to WRC
• [Delegates] Handle WCA ID claim request

3. Help to reduce columns from many tables
   The table to which it can be moved are explained later below.

• users

  • pending_avatar: Can be moved to ticket_avatar_request.
  • unconfirmed_wca_id: Can be moved to ticket_wca_id_claim_request.
  • delegate_id_to_handle_wca_id_claim: Can be moved toticket_wca_id_claim_request.

• Competitions

  • results_posted_at: Can be moved to ticket_results_import.
  • results_submitted_at: Can be moved to ticket_results_import.
  • results_posted_by: Can be moved to ticket_results_import.
  • posting_by: Can be moved to ticket_results_import.

I strongly believe that there can be much more scopes for reducing columns from table.

Ticket types and corresponding metadata table

1. EditPersonRequest (table: ticket_edit_person_request)
2. EditResultRequest (table: ticket_edit_result_request)
3. GeneralCommentWrt (table: ticket_general_comment_wrt)
4. AvatarChangeRequest (table: ticket_avatar_change_request)
5. ResultsImport (table: ticket_results_import)
6. GeneralCommentWrc (table: ticket_general_comment_wrc)
7. MediaRequest (table: ticket_media_request)
8. CompetitionAnnouncementRequest (table: competition_announcement_request)
9. CompetitionDuesRequest (table: ticket_competition_dues_request)
10. WrcIndicentDiscussion (table: ticket_wrc_incident_discussion)
11. WcaIdClaimRequest (table: ticket_wca_id_claim_request)

I don’t have the plans for the columns for each of them, but have a small idea on couple of them: they are as follows:

1. ticket_edit_person_request

id: integer
person_id: string
old_name: string
new_name: string
old_country_iso2: string
new_country_iso2: string
old_gender: string
new_gender: string
old_birthdate: string
new_birthdate: string

2. ticket_general_comment_wrt

id: integer
request_message: string

Action plan

Implementing all of the above is very difficult. But initial tasks that will be done are:

1. Implement tickets table and ticket_general_comment_wrt, along with the UI to redirect contacts to WRT to this ticket. WRT will also get a ‘ticket dashboard’ in WRT panel, in which they can see the tickets and respond there directly. Once closed, all the messages can be sent to email for documentation purposes if needed.
2. Implement ticket_edit_person_request: The current edit person form will be extended to delegates, so that delegates can use that form to request change in person details. At this point, WRT’s ticket dashboard will get filter options like ‘all tickets’, ‘general comment tickets’, ‘edit person tickets’, etc.

Further plans are currently not listed, but slowly people can take up migrating different stuffs mentioned here to tickets.