Documentation
¶
Overview ¶
Package ticket implements the ticket subdomain of the support module. Only the module facade (internal/module/support) may reach it.
Index ¶
- type AuditLog
- type CreationLimiter
- type Limits
- type Notifier
- type Service
- func (s *Service) CreateFollow(ctx context.Context, req *dto.CreateTicketFollowRequest) error
- func (s *Service) CreateUserFollow(ctx context.Context, req *dto.CreateUserTicketFollowRequest) error
- func (s *Service) CreateUserTicket(ctx context.Context, req *dto.CreateUserTicketRequest) error
- func (s *Service) GetDetail(ctx context.Context, req *dto.GetTicketRequest) (*dto.Ticket, error)
- func (s *Service) GetUserDetail(ctx context.Context, req *dto.GetUserTicketDetailRequest) (*dto.Ticket, error)
- func (s *Service) GetUserList(ctx context.Context, req *dto.GetUserTicketListRequest) (*dto.GetUserTicketListResponse, error)
- func (s *Service) List(ctx context.Context, req *dto.GetTicketListRequest) (*dto.GetTicketListResponse, error)
- func (s *Service) UpdateAsStaff(ctx context.Context, cmd *dto.StaffTicketUpdateCommand) (*dto.StaffTicketUpdateResult, error)
- func (s *Service) UpdateStatus(ctx context.Context, req *dto.UpdateTicketStatusRequest) error
- func (s *Service) UpdateUserStatus(ctx context.Context, req *dto.UpdateUserTicketStatusRequest) error
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type AuditLog ¶ added in v1.21.0
AuditLog records the administrators' ticket mutations in the platform's system log; the platform kernel's log repository satisfies it.
type CreationLimiter ¶ added in v1.21.0
type CreationLimiter interface {
// Allow takes one permit for the user and reports whether it was
// granted.
Allow(ctx context.Context, userID int64) (bool, error)
}
CreationLimiter caps how many tickets, or replies, one user may write per window.
func NewCreationLimiter ¶ added in v1.21.0
func NewCreationLimiter(rds *redis.Client) CreationLimiter
NewCreationLimiter backs the ticket creation limit with Redis; a nil client disables it.
func NewFollowLimiter ¶ added in v1.21.0
func NewFollowLimiter(rds *redis.Client) CreationLimiter
NewFollowLimiter backs the reply limit with Redis; a nil client disables it.
type Limits ¶ added in v1.21.0
type Limits struct {
// Creation caps how many tickets one user opens per window.
Creation CreationLimiter
// Follows caps how many replies one user writes per window: every reply
// is mirrored into the Telegram admin group.
Follows CreationLimiter
}
Limits are the per-user caps of the user-facing ticket writes; a nil limiter turns its cap off.
type Notifier ¶ added in v1.15.18
type Notifier interface {
TicketCreated(ctx context.Context, t *entity.Ticket)
TicketReplied(ctx context.Context, ticketID int64, from, content string)
TicketStatusChanged(ctx context.Context, ticketID int64, status uint8)
}
Notifier mirrors ticket lifecycle into other channels — today the forum topic in the Telegram admin group. Implementations are best-effort by contract: they never fail the ticket operation, so the methods return nothing and do their own logging.
type Service ¶
type Service struct {
// contains filtered or unexported fields
}
Service runs the ticket desk for the support facade.
func NewService ¶
func NewService(repo repository.TicketRepo, notify Notifier, limits Limits, audit AuditLog) *Service
NewService builds the ticket service; notify may be nil when no mirror channel is wired, the limits nil when the user writes are not rate limited, audit nil when the administrators' actions are not recorded.
func (*Service) CreateFollow ¶
CreateFollow appends an admin reply and flips the ticket back to Waiting. A closed ticket takes no reply until it is reopened.
func (*Service) CreateUserFollow ¶
func (s *Service) CreateUserFollow(ctx context.Context, req *dto.CreateUserTicketFollowRequest) error
CreateUserFollow appends a user reply, within the reply limit, after verifying ticket ownership, and flips the ticket to Pending. This is the product rule for closed tickets as well: the owner's reply reopens a closed ticket, since the owner has no other way to say the matter is not settled; staff, in contrast, must reopen a ticket explicitly before replying. The author is always the ticket owner: a client-supplied "from" would let a user post what renders as a staff reply.
func (*Service) CreateUserTicket ¶
CreateUserTicket opens a ticket for the current user, within the creation limit, and mirrors it.
func (*Service) GetUserDetail ¶
func (s *Service) GetUserDetail(ctx context.Context, req *dto.GetUserTicketDetailRequest) (*dto.Ticket, error)
GetUserDetail returns one of the current user's tickets with its follows.
func (*Service) GetUserList ¶
func (s *Service) GetUserList(ctx context.Context, req *dto.GetUserTicketListRequest) (*dto.GetUserTicketListResponse, error)
GetUserList pages the current user's tickets.
func (*Service) List ¶
func (s *Service) List(ctx context.Context, req *dto.GetTicketListRequest) (*dto.GetTicketListResponse, error)
List pages the tickets of every user, or of one, for the admin panel.
func (*Service) UpdateAsStaff ¶ added in v1.21.0
func (s *Service) UpdateAsStaff(ctx context.Context, cmd *dto.StaffTicketUpdateCommand) (*dto.StaffTicketUpdateResult, error)
UpdateAsStaff applies a ticket change staff made outside the admin panel: a reply is appended as a text follow and moves the ticket to Waiting, like a reply from the admin panel; otherwise the ticket moves to cmd.Status. A reply to a closed ticket is refused with entity.ErrClosed; a status change is the explicit reopen. A missing ticket is an error whose chain holds gorm.ErrRecordNotFound. The channel records its own audit trail.
func (*Service) UpdateStatus ¶
UpdateStatus moves a ticket to the status staff chose in the admin panel. As for a change from the bot, the status must be one of the four ticket statuses and the ticket must exist; otherwise nothing is stored or mirrored.
func (*Service) UpdateUserStatus ¶
func (s *Service) UpdateUserStatus(ctx context.Context, req *dto.UpdateUserTicketStatusRequest) error
UpdateUserStatus lets a user close their own ticket. Closing is the only status change the product offers users: Waiting and Processed are staff decisions, and a reply is what moves a ticket back to Pending. Ownership is checked before anything changes, because the status mirror reaches the Telegram admin group.