This wiki was in read-only mode for many years, but can now be edited again. A lot of information will need to be updated.
Update Membership Request: Difference between revisions
Grans Remedy (talk | contribs) New page: {{DesignDocument}} == Introduction == This use case describes the process a group manager will use to approve or decline a request from a player to join a group. [[Image:UC_Update_Membe... |
category link |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{Specification}} | ||
== Introduction == | == Introduction == | ||
| Line 47: | Line 47: | ||
'''RQ15 Notify player of changes''' <br /> | '''RQ15 Notify player of changes''' <br /> | ||
The system shall notify the player who submitted the request of any change in its status. <br /> | The system shall notify the player who submitted the request of any change in its status. <br /> | ||
| Line 72: | Line 71: | ||
Message Text:= The membership request has been updated, and the player notified of the result. | Message Text:= The membership request has been updated, and the player notified of the result. | ||
</properties> | </properties> | ||
[[Category:Group Manager]] | |||
Latest revision as of 17:06, 5 December 2016
|
This page contains a specification document for an enhancement or feature. It is a work of collaborative development, and may not represent the final design. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design. |
Introduction
This use case describes the process a group manager will use to approve or decline a request from a player to join a group.
The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).
Pre-conditions
None
Post conditions
The membership request has been updated.
Requirements and rules realized
RQ11 Track the status of membership requests
The system shall store and track the status of membership requests.
- BR19 Record change in request status
The system shall record the change in status from 'pending' to 'actioned', and optionally a note, for each request when one of the groups managers has indicated the outcome of the request.
- BR20 Record request result
The system shall record the result of each request which shall be either 'approved' or 'declined', along with the date of the decision, the manager who made it and optionally a note.
- BR21 Membership request information
The system shall record the player, date, group and optionally a note from the player for each membership request.
- BR25 Actioned requests cannot be updated
The system shall prevent a request which has already been actioned from having its result changed.
RQ14 Viewing membership requests
The system shall enable players to view the requests they have submitted.
- BR22 Group managers view all requests
The system shall enable group managers to view all requests, both pending and actioned, for the groups they manage.
RQ16 Format of request list
The system shall format the list of membership requests according to the following rules: BR23, BR24
- BR23 Group by namespace
The system shall enable the actor to view the requests belonging to each namespace separately.
- BR24 Filter by status
The system shall enable the actor to filter the requests by status; viewing only those 'pending', 'resulted', or both.
RQ15 Notify player of changes
The system shall notify the player who submitted the request of any change in its status.
Flow of events
The flow of events describes the main actor actions and system responses in the execution of the use case.
Messages
<properties> Step:= BF-3 Condition:= Actor indicated update request Message Number:= MSG-1 Message Text:= Please confirm that you want to <approve | decline> this request. </properties>
<properties> Step:= BF-7 Condition:= Request updated Message Number:= MSG-2 Message Text:= The membership request has been updated, and the player notified of the result. </properties>