Merge branch '87-check-list-indentations' into 'dux'

The exercise designer must be clear about three things for each LA:

1. **What specifically the participant is to do/practice**. For example, he/she has to decide,

    analyze, present, discuss, etc. The chosen activity must make sense in relation to the LO to

    which the LA relates.

2. **How will the participants\`action manifest itself in the platform** If we omit this step, it is

    difficult for us to measure the fulfilment of the action. This condition does not mean that

    everything during the exercise must happen directly in the platform. For example, you can give

    participants an LA which purpose will be to discuss an issue in detail; we will link it to the

    platform with a confirmation button (described further) that participants activate at the end

    of the discussion. This step is fundamentally related to the following one and cannot be simply

    separated.

3. **We need to know which inject will trigger this LA**. In other words, the LA will not happen

    unless the participant receives the necessary cue. It is not necessary for each LA to have a

    specific inject. On the contrary, one inject can easily become the source for several LAs. For

    example, a simple incident report will trigger a series of LAs based on the incident response

    plan.

1. **What specifically the participant is to do/practice**.

    For example, he/she has to decide, analyze, present, discuss, etc.

    The chosen activity must make sense in relation to the LO to which the LA relates.

2. **How will the participants\`action manifest itself in the platform.**

    If we omit this step, it is difficult for us to measure the fulfilment of the action.

    This condition does not mean that everything during the exercise must happen directly in the platform.

    For example, you can give participants an LA which purpose will be to discuss an issue in detail;

    we will link it to the platform with a confirmation button (described further) that participants activate

    at the end of the discussion.

    This step is fundamentally related to the following one and cannot be simply separated.

3. **We need to know which inject will trigger this LA**.

    In other words, the LA will not happen unless the participant receives the necessary cue.

    It is not necessary for each LA to have a specific inject.

    On the contrary, one inject can easily become the source for several LAs.

    For example, a simple incident report will trigger a series of LAs based on the incident response plan.

## How to specify Learning Activities?

An example of such a file can be

[downloaded](https://gitlab.fi.muni.cz/inject/inject-docs/-/raw/dux/docs/tech/example_csv.csv?ref_type=heads&inline=false).

The CSV file can be also used for the bulk adding of a new tags. If the platform detects username

(email) that already exists on the platform it skips the creation and sending of the credentials and

only adds new tags for such users. Meaning that if you modify tags in a CSV that you already used

for the account creations you will achieve bulk adding of a new tags (no other fields will be

changes).

The CSV file can be also used for the bulk adding of a new tags.

If the platform detects username (email) that already exists on the platform

it skips the creation and sending of the credentials and only adds new tags for such users.

Meaning that if you modify tags in a CSV that you already used for the account creations

you will achieve bulk adding of a new tags (no other fields will be changes).

This requires access to an SMTP server.

### Through the web interface

It is also possible to create individual user accounts through the API. This is accessible through

the frontend on the `Users` page if you have `INSTRUCTOR` or `ADMIN` role. Once created, the server

sends an invitation email with credentials to the given email address.

It is also possible to create individual user accounts through the API.

This is accessible through the frontend on the `Users` page if you have `INSTRUCTOR` or `ADMIN` role.

Once created, the server sends an invitation email with credentials to the given email address.

Also requires access to an SMTP server.

    docker exec -it CONTAINERNAME python manage.py shell

    ```

- Create a user using the Django shell. Replace `email@test.com` and `long_and_secure_password` with

    your desired user credentials (by default a user with a _TRAINEE_ authorization group is

    created):

- Create a user using the Django shell.

    Replace `email@test.com` and `long_and_secure_password` with your desired user credentials

    (by default a user with a _TRAINEE_ authorization group is created):

    ```python

    from user.models import User

    User().set_email_username("email@test.com").set_password("long_and_secure_password").save()

    ```

````

- if you want to create account with an _INSTRUCTOR_ authorization group:

    - if you want to create an account with an _INSTRUCTOR_ authorization group:

        ```python

        User(group=User.AuthGroup.INSTRUCTOR).set_email_username("email@test.com").set_password("long_and_secure_password").save()

        ```

- if you want to create account with an _ADMIN_ authorization group:

    - if you want to create an account with an _ADMIN_ authorization group:

        ```python

        User(group=User.AuthGroup.ADMIN).set_email_username("email@test.com").set_password("long_and_secure_password").save()

        ```

````

## Assigning users to exercise

### Manual assignment

You can assign users 'manually' by adding one or multiple users to a team or removing them,

utilizing the list of all present users on the platform. This use case is ideal for situations when

the distribution of users into teams is uncertain during preparation, or for situations when you

need to edit semi-automatically created assignments.

utilizing the list of all present users on the platform.

This use case is ideal for situations when the distribution of users into teams is uncertain during preparation,

or for situations when you need to edit semi-automatically created assignments.

### Semi-automatic assignment

    - _Number of users < number of teams_: First _n_ teams will be assigned one user each. The

        remaining teams (number_of_teams - number_of_users) will be left empty.

    - _Number of users = number of teams_: Every team will have exactly one assigned user.

    - _Number of users > number of teams_: Starting with the first user, placing him/her on the first

        team. Then, moving to the second user and placing him/her on the second team, and so on. Once

        a user is assigned to the last team, the algorithm loops back around and assigns the next user

        to the first team. This continues until all users are assigned to a team. Example situation –

        assigning 10 users (user1 to user10) to 3 teams would end up with this distribution:

    - _Number of users > number of teams_: Starting with the first user, placing him/her on the first team.

        Then, moving to the second user and placing him/her on the second team, and so on.

        Once a user is assigned to the last team, the algorithm loops back around and assigns the next user to the first team.

        This continues until all users are assigned to a team.

        Example situation – assigning 10 users (user1 to user10) to 3 teams would end up with this distribution:

        - team1: user1, user4, user7, user10

        - team2: user2, user5, user8

        - team3: user3, user6, user9

- If some users are already assigned to the exercise, they will not be reassigned based on the new

    assignment.

- If some users are already assigned to the exercise, they will not be reassigned based on the new assignment.

- WARNING: This feature _does not work_ with _role exercise_.

#### **Assign by tags**

- The platform automatically distributes users to teams based on the tags (with chosen prefix) of

    the selected users. Let's illustrate this functionality on the following example:

    - Imagine, we have users (trainees) and their tags in the brackets (these tags were assigned via a

        CSV file):

- The platform automatically distributes users to teams based on the tags (with chosen prefix) of the selected users.

    Let's illustrate this functionality on the following example:

    - Imagine, we have users (trainees) and their tags in the brackets (these tags were assigned via a CSV file):

        - trainee1 (PowerPlantTTX-team1, HealthCareEX-team3)

        - trainee2 (PowerPlantTTX-team1, HealthCareEX-team2)

        - trainee3 (PowerPlantTTX-team3, HealthCareEX-team3)

        - trainee4 (PowerPlantTTX-team2, HealthCareEX-team1)

    - Now, we want to assign trainees 1-4 to our tabletop exercise about a power plant crisis. We knew

        beforehand how we wanted to distribute them to teams in this exercise and created the

        appropriate tags. We used `PowerPlantTTX` or `PowerPlantTTX-` as our prefix to distinguish

        between other tags. - The platform will now take the selected users and find a tag with a

        given prefix (which must be provided, in our case `PowerPlantTTX`) for each user. The users

        will be assigned by lexicographic ordering of suffix parts. In this case:

    - Now, we want to assign trainees 1-4 to our tabletop exercise about a power plant crisis.

        We knew beforehand how we wanted to distribute them to teams in this exercise and created the appropriate tags.

        We used `PowerPlantTTX` or `PowerPlantTTX-` as our prefix to distinguish between other tags.

    - The platform will now take the selected users and find a tag with a given prefix

        (which must be provided, in our case `PowerPlantTTX`) for each user.

        The users will be assigned by lexicographic ordering of suffix parts.

        In this case:

        - trainee1 and trainee2 will be assigned to the first team

        - trainee4 will be assigned to the second team

        - trainee3 will be assigned to the third team

    - If we used `HealthCareEX` as the wanted prefix for the user assignment, we would end up with: -

        trainee4 in the first team - trainee2 in the second team - trainee1 and trainee3 in the third

    - If we used `HealthCareEX` as the wanted prefix for the user assignment, we would end up with:

        - trainee4 in the first team

        - trainee2 in the second team

        - trainee1 and trainee3 in the third

            team

- The following **rules have to be complied with** to make this assignment possible:

    - Prefix parts have to be unique for a given assignment (which can be achieved by making them long

            _b_ to second...)

        - Exercise-t1, Exercise-t2, Exercise-t3 (those with _t1_ will be assigned to first team, those

            with _t2_ to second...)

    - If more tags match the prefix than the number of present teams, the operation will fail. Either

        the number of teams has to be increased, users with tags that exceed the number of teams would

        need to be removed from selection, or the exceeding tags would need to be removed.

    - If more tags match the prefix than the number of present teams, the operation will fail.

        Either the number of teams has to be increased, users with tags that exceed the number of team

        would need to be removed from selection, or the exceeding tags would need to be removed.

- WARNING: This feature does not work with _role exercise_.

#### **Copy existing assignment**