cntodev/rooster

Community Roster and related automation services for managing members

rooster's Issues

New members e-mail verification

When an Application Form is accepted, a new member should be created. Since a new applicant has no ways to enter credentials in the submission of the application form, an email should be sent both for verification purposes and for setting a password to log in.

Do we need this for the MVP @milivojm ?

Add Creator DLC CSLA Iron Curtain to CNTO Server Launcher

Just a nice to have but with the release of the latest Creator DLC it would be neat to be able to activate it on the server on-demand like GM and VN.

Completely non-urgent feature request!

Permissions management design

Discussion for permissions management service design.

Member login

TBD

Logging not available on Docker

Serilog is configured to log onto local folder which is not mapped to external volume in Docker. That means only by directly connecting to docker container you can observe what's going on.

• create a docker volume for logs
• configure serilog file logging to log in appropriate mapped directory
• update docker run script to mount a volume

Add a `bootcamp` field on Recruit's profile

The field should be only editable by Interviewers and is tied to the warnings system.

A recruit must pass the mod assessment and bootcamp within 2 weeks of joining.

Guidelines for service design

Design of a service should happen in this repository to keep track of what has been done, how and why certain choices have been made. Also, this is to help future maintainers learning how the various services work.

Each service should have a dedicated space for its design discussion (i.e. an issue). Even if developing it as a one-man-army do provide a comprehensive documentation of the choices that were made and, most importantly, how it behaves concerning inputs, outputs and events.

Formally, the bare minimum requirements for a design document should be as follow:

1. General aim of the service (what it does)
2. Exposed endpoints and communication protocol(s). When possible, follow industry standards for API documentation (i.e. openapi for REST APIs)
3. Events the service generates and what they mean. Each service should use a first-level or second-level (with cntoroster prefix for the latter case) prefix for each event it generates. For example, service Foo generating events beer spilled and out of beer should use events such as foo.beer_spilled and foo.out_of_beer, or cntoroster.foo._xxx (stick to the already in use case and naming convention).

For the sake of storage re-usability, also document which storage technology is used and how the data is structured if possible.

Finally, documentation of the source code of the service itself is a nice to have but not required, as the idea behind the architectural choice of microservice-based system is to make each service disposable.

User makes discharged member rejoin active member base

Integrate with Discord

When Member gets promoted, assign appropriate tags on Discord.

MemberPromoted event should be listened.

User discharges member

Pre-conditions

• member is an active member
• user has to have appropriate permission - DischargeMember claim

Main flow

1. post method DischargeMember with following arguments have been called by FE service (MemberId, User)
2. service checks if User has DischargeMember claim.
3. service reads Member from Repository and checks if Member is Active.
4. service toggles Member Active atribute.
5. service stores Member in the Repository.
6. service published MemberDischarged event on the event bus. Event has to contain (MemberId, Time, UserId)
7. HTTP Response should be returned 200+ with JSON data success.

Alternative flows
Member is not active any more
3a. service returns 400.
User doesn't have the permission
2a. service returns 401.
Member not found
3a. service returns 404.

Post-conditions
Member Active attribute has been set to false. MemberDischarged event has been created.

User adds member to a community branch

System updates attendance data

User creates new community member

Pre-conditions

• user has permission - CreateMember claim
• a member with the same nickname does not exist already

Main flow

1. put method CreateMember with following arguments is called (Member, User)
2. service checks if User has CreateMember claim
3. service reads all Members from Repository and checks if members with nickname of new Member exist
4. service creates new Member
5. service stores new member in Repository
6. service publishes MemberCreated event on the event bus. Event has to contain (Member, Time, UserId)
7. http response is returned with status code 200+ and URL to location of the created member

Alternative flows
User does not have permissions
2a. service returns 401
Member with same username already exists
3a. service returns 409

Post-conditions

• new Member has been created and saved
• MemberCreated event has been created

Member details

Member details page would be nice Highway.

User cancels LoA for member

Assigning ranks to members

Make all Ranks available (Recruit, Reservist, Grunt, Specialist, Corporal and Staff Sergeant) for promoting/demoting members.

Different ranks can be assigned by different people, thus the permission system should be updated accordingly.

I am not currently aware whether the community already has guidelines for which ranks/branch members can assign which ranks to other members (pinging @JamesTheClarke here to make sure). But ideally it should be something like this:

• only Interviewers and SSgts can promote a Recruit to the Reservist rank
• only Member Managers and SSgts can promote/demote Reservists, Grunts and Specialists to either three of those ranks (although a valid alternative would be to make only Branch managers be able to promote members to the Specialist rank, but that would require the Branch system to be in place so it can wait)
• only SSgts can promote members to Corporal and Staff Sergeant

Warnings system

There are several warnings to be shown to both Interviewers and Member Managers.

• when a member hasn't attended enough events (2 events in the past month)
• when a recruit's 8 week probation phase is close to ending
• when a recruit is close to not fulfilling their mod assessment (due 2 weeks from joining)

I'm sure there are going to be many other warnings that are either already in the django-roster or that could be useful to introduce. But I would stop with the three listed above for the MVP.

For the UX bit, different roles should see different warnings and only relative to their branch. For example, Interviewers should not be able to see warnings for Member Managers and viceversa. Also, displaying the warnings on the frontend should allow for some basic search and filtering features.

@milivojm if you agree this is enough for the MVP I can go ahead and split this into different sub-tasks.

Event tracking

Discussion for how the attendance tracker should work.

The django-roster uses a complicated way of parsing an list of attendees through Steam's API every X time during a scheduled event (Tuesday and Friday). We could greatly simplify the logic, pasting Discord convo between myself and @milivojm.

1. Define the concept of community event and make it editable by someone (i.e. Tuesday and Friday events with start and end time). This means defining something like ArmaEventRecurrence that should be editable by users to identify community events that we want to gather attendance data of.
2. Have something kick off an event tracker at the start of each event, essentially starting a recording of what happens on the server. MassTransit can handle scheduled domain events (i.e. ArmaEventStarted) and it already works for handling the recruitment stage.
3. Have a set of code that constantly (i.e. every minute) checks who is online through Steam's API and matches the retrieved usernames with the members of the community (from Roster). The frequency of polling Steam API can be arbitrarily changed and should be included in a setting. Do we keep data in memory (dangerous if the service breaks) or do we store it in the DB (slower)?
4. Once the event has finished, the tracking script should update the attendance for said event in a streamlined format (i.e. only username and attendance ratio, like what percentage he/she/they were logged with respect to the event duration). The attendance service could raise a storm of ArmaEventAttended with information regarding Nickname, Ratio, ArmaEventId and consumers can then store the data in the DB.
5. Take it from there on the domain level to check attendance (i.e. attendance over 50% means event attended). On the domain level we can issue a EnoughEventsAttended event for recruits when they attend more than the required amount of events within 8 weeks and a MemberWarning event for existing members (Reservists and above) if their attendance ratio drops below the minimum required.

Attendance tracking Service

Discussion for attendance tracking service design.

Use cases involved:

1. System updates attendance data

Member management Service

Discussion for member management service design.

Use cases involved:

1. User discharges member
2. User creates new community member
3. User makes discharged member rejoin active member base

Previous/next pagination

On members page, previous/next page is bugged.

Branches Service

Discussion for branches management and branch membership service design.

Use cases involved:

1. User updates member role within a community branch
2. User removes member from a community branch
3. User adds member to a community branch

System updates member roles according to attendance and LoAs

Use HTTP only

This is high priority. Since Roster will be deployed with reverse proxy, enforcing HTTPS redirection + HSTS middleware is not needed.

User updates member role within a community branch

Automated permissions on TeamSpeak3

Following up from #35.

MVP-wise the feature should be limited to Recruits being promoted to Reservists, although if rank system is already in place any update in the rank group can be handled.

When a member gets their rank updated, the change should be reflected on the community's TeamSpeak 3 server based on the member's TS3 id. We need to look into TS3 API for this as it is unclear whether it's possible or not.

User demotes member to lower rank

MVP Automation level

Opening this to centralize the discussion about whether automation of features mentioned in #62, #63, #64, #66 should be part of the MVP milestone.

Whilst it is definitely something we want in the Roster, I think implementing it right away creates two different issues:

1. Longer development time. In my opinion MVP should be delivered as fast as we possibly can so we don't have to maintain the django-roster project anymore. Developing automation from the get go would significantly increase time to transition. Also, I do think we need to keep the manual version of those features anyway in case something breaks or for control purposes, then build automation on top of that.
2. Explitic reasoning. Whilst this mostly concerns #64 the idea is still valid: automation must be transparent, in the sense that every action taken by some "reasoning" must be shown to end users (Interviewers or Member Managers). An event-oriented design for the automation feature would work great to support reasoning, but it would take some time to discuss, design and finally implement.

User inserts LoA time window for member

Ranks Service

Discussion for ranks management service design.

Use cases involved:

1. System updates member roles according to attendance and LoAs
2. User demotes member to lower rank
3. User promotes member to higher rank

User grants access to Roster to member

Automated permissions on Discord

Following up from #35.

MVP-wise, when a Recruit is promoted to Reservist the change should be reflected on the community's Discord server. In general this should happen at every rank update for a member.

I haven't still looked into Discord API but there's a good chance this is easily doable.

Access denied HTTP redirect

When user doesn't have permissions to access a page, application redirects to HTTP page resulting in 532 response. Possible solutions:

• expose 443 in the container forcing HAProxy to use HTTPS
• use URL rewriting on HAProxy (HTTP -> HTTPS)

Finalize member application

Members (interviewers only when branch membership will be defined, outside MVP) can either accept or refuse a submitted application form.

In case of acceptance: a new member for the applicant is created, recruit rank is assigned (when rank system will be defined, outside MVP), community services eligible for automation are updated (i.e. applicant is automatically added the tag of recruit on Discord).

Server Auto-Restart before Operations

A while ago @Shiny-CNTO tried to implement an option whereas the game server restarts Tuesdays and Fridays at 19:30 with the Main Repo.

However, it hasn't really worked properly yet so I'd like to request a new feature for the game server launcher:

• auto-restarts of the game server Tuesdays and Fridays at 19:30 GMT+1
• the auto-restart should use the server settings pre-restart. Meaning if Main + Campaign + 1HC was running before, restart with Main + Campaign + 1HC.

General architecture

This issue acts as place for discussing the general architecture of the new system.

Taking into consideration the project requirements (ease of maintenance, add features later on, connecting multiple community services, support several programming languages), a microservice approach makes more sense than developing a traditional, full-stack application.

The application will be split in the following services for version 1.0, which aims at replacing the current Roster system.

• Member management
• User authentication and authorization (or security service)
• Branch and branch membership management
• Rank management (ranks, member promotion and demotion, recruit constraints)
• Leave of absence management
• Permission system
• Attendance tracking

User modifies LoA for member

Refresh DLC list

DLC list in the Roster needs update.

Show deadlines for Recruits

While in the probation phase, a deadline for the 8 week long time window should be shown to Interviewers to inform them about how long the Recruit has to attend the minimum amount of OPs.

This is how it currently works on the django-roster, although it might be worthwhile to seek for a better system of checks to better understand which requirements the Recruit is/isn't fulfilling. For example, since the community states a few deadlines for the probation phase (i.e. how long before Mod Assessment), a more detailed set of conditions would be a good improvement.

For the time being though, I'd focus on replicating the existing feature and leaving up to Interviewers to double check with the attendance data.

Promotion to Reservists rank

When a Recruit passes the requirements of their probing phase, Interviewers must be able to promote them to the Reservist rank.

Roster application form submission

Make community applicants submit an application form, validate it then store it.

Implement e-mail verification on user registration

Once Roster user fills in registration form, Roster should send him an e-mail instead of default verify here page. Right now it's confusing and users get stuck in dead space.

Check list and details of submitted application forms

Every member (interviewers only when branch membership will be defined, outside MVP) should be able to list and check out application forms that have been submitted.

User removes member from a community branch

Permissions page

Create a page where admin can assign claims to users. Right now I'm doing it through database which is not desirable.

Abandon `flask-restful` for standard `flask` library

The current (basic) implementation of the member service is based on flask restful library, which the author does not recommend using anymore. Since Flask 2.0 is about to be released and there are no plans to update flask-restful, and since the features of the package are already present in Flask itself (flask-restful/flask-restful#883) a refactoring is due in order to drop the dependency on flask-restful.

User authentication and authorization Service

Discussion for user authentication and authorization service design.

Use cases involved:

1. User grants access to Roster to community member

User promotes member to higher rank

Order of fields on application form

May I suggest changing the order of the entries? For example, why is steam on the bottom and not on top? GitHub is higher then teamspeak? That sort of thing. Also, add a short explanation to Bohemia interactive nickname because if left without it will be very confusing to new players.

Leave of absence management Service

Discussion for LoAs management service design.

Use cases involved:

1. User inserts LoA time window for member
2. User modifies LoA for member
3. User cancels LoA for member