====== Admins's Guide ======
<todo @pczekalski>Do an admin's guide</todo>
The system has two kinds of administrators: the Super Admin, a built-in account, and any number of Laboratory Admins.
To understand activities and relations, it is essential to recognise system-building components (figure {ref>vrelsoftware2}).
<figure vrelsoftware2>
{{ :en:iot-open:practical:software:vrel.drawio.png?600 |}}
<caption>VREL Nextgen building components</caption>
</figure>

===== Super Admin =====
The Super Admin can create new Laboratory Admins by promoting the regular user's account or explicitly creating a new one.\\
The Super Admin can also create a laboratory (a group of administrators) and assign Administrator's (Administrators') accounts to it, remove admins and manage individual Users.

===== Admin =====
The Admin's role is to configure the system per laboratory and manage cohorts of students (Users) and individual devices. There can be many Admins in the system, and each can manage their own Users, Laboratories (called Group of Devices) and individual Devices.

Regular Admin has several scenarios:
  * User management: 
    * editing User's data, 
    * delete the User's project files (Cleanup).
  * Managing group of users: 
    * creating and deleting user groups,
    * adding and removing users to and from the group.
  * Managing a Group of Users in the context of the devices: 
    * assign existing devices to the Group, removing device assignments from the User's Group.
  * Managing Groups of Devices (Laboratory):
    * creating and deleting a Group of Devices (Laboratory),
    * managing individual Devices' assignment to the Group of Devices
  * Configuring and managing individual Devices:
    * creating and editing a Device with detailed technical documentation, deleting the device,
    * cleaning up devices (deletes compilation targets),
  * Managing User's bookings (per device).

Below there are some hints and important information:
  - User Groups bind Users and Devices: Users can book Devices if both are in the same group. The User can be a member of many groups. Groups typically reflect student groups (such as the Dean's group or laboratory team), and devices assigned to the group reflect module-related resources that are needed to perform lab work.
  - Admin-level access to the Bookings is possible via the Devices menu (then expand the group and the device and check for Bookings in the context menu).
  - Users' projects (source codes) can be cleaned up in the Users menu.
  - Laboratory compiled and temporary files can be cleaned up in the Devices' context (Devices menu).
  - Compiler service uses a single source file on the input, which is PlatformIO-based. Thus, all source codes constituting a project are single cpp (or other) files + platformio.ini files.

==== Admin: device configuration ====
Device configuration is the most complex part of the administration process. It requires the correct configuration of the end node proxy service regarding the specification of the target IoT device it manages. It is a compilation service (figure {{ref>vrelsoftware2}}) that executes compilation commands and execution.\\
The device configuration supports several configuration parameters, many of which may be redundant or unnecessary, to ensure flexibility among different IoT hardware.
Commands to compile and upload firmware (or configuration) are Admin-defined. Besides common configuration parts such as name, location, and description, there are sections for:
  * Device reset (reboot, restart)
  * Code compilation, including check of the success with standardised return signalling to the system
  * Code execution (i.e. firmware upload)
<note tip>Aforementioned actions can have more than one command, and each command can be an SSH or CMD (bash) command.</note>
<note tip>There are wildcards that represent some critical information, e.g. source file name, target location etc. Those can be used in commands and passed as parameters to the external scripts that can be executed (CMDs).</note>