A demo using with pre-loaded data is available for local execution. It comes with various accounts from regular user to an admin user. To run locally this instance you need to have docker installed on your computer, then run ``docker run -p 127.0.0.1:8086:8086/tcp viralhostrange/demo`` and then open in your browser http://127.0.0.1:8086. Here after are detailed the accounts, and their ability
Admin
| **username**: admin
| **password**: adminadmin
| **description**: This user is an admin and a :ref:`curator <curator-role-label>`. It can explore the admin interface of the application.
Alice
| **username**: alice
| **password**: alicealice
| **description**: This user is a regular user, owner of the private data source `alice data source` which is shared with user bob, with edition permission.
Bob
| **username**: bob
| **password**: bobbob
| **description**: This user is a regular user, it can see and edit the data source `alice data source`.
Deploying a local instance
----------------------------------------
Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The architecture is designed to run on a `kubernetes cluster <https://kubernetes.io/>`_. The public instance running at https://viralhostrangedb.pasteur.cloud/ is automatically deployed with the continuous deployment of gitlab. Procedure to deploy an instance can be seen in `.gitlab-ci.yml <https://gitlab.pasteur.fr/hub/viralhostrangedb/-/blob/master/.gitlab-ci.yml>`_. Several environment variable are needed and are detailed hereafter :
DEPLOY_TOKEN
Let the CI/CD access to your local docker registry to push/pull the images
DEPLOY_USER
Same as DEPLOY_TOKEN
NCBI_API_KEY
Querying the Entrez API of the NCBI in order to determine if identifier are valid in the NCBI(cf `here <https://ncbiinsights.ncbi.nlm.nih.gov/2017/11/02/new-api-keys-for-the-e-utilities/>`_)
NCBI_EMAIL
Same as NCBI_API_KEY
POSTGRES_PASSWORD
The password that will be associated to the postgres user used by the application.
SECRET_KEY
Needed by django (cf `here <https://docs.djangoproject.com/fr/2.2/ref/settings/#std:setting-SECRET_KEY>`_)
USE_SQLITE_AS_DB
Indicate to not use SQLITE, but POSTGRES instead. Must be set to `False` for a production instance.
.. _create-superuser-label:
What to do first
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once deployed, the application will initialize the database and then make the instance up and running. At this point there is no superuser user. As owner of this instance you have to access to your ViralHostRangeDB instance in a web browser and create an account. The first user to create an account become superuser. (also skip the part where the email have to be validated before enabling the account).
Manage a local instance
----------------------------------------
Great power great responsibility
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your are a manager of the instance, you might also be a regular user or curator of the application. It is highly recommended to not use the :ref:`<superuser account> create-superuser-label` for you user/curator work: use the superuser account for administration works, and use your regular account for browsing, contributing and curating. This division of responsibility in two account reduces the chances of the application being compromised with, for example, a superuser session forgotten opened on a browser.
Defining an user as curator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To do so, do to the admin interface https://viralhostrangedb.pasteur.cloud/admin/auth/group/ and open the ``Moderator`` group. On the lower part you see all the users, and which are curators. Note that curators are listed in https://viralhostrangedb.pasteur.cloud/about/. Only `superuser <https://docs.djangoproject.com/fr/2.2/ref/django-admin/#createsuperuser>`_ can define a user as curator.
Defining an user as "staff" (i.e: an admin)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Defining a user as staff does not provide any permission by itself.
A staff curator/moderator
Defining a user as staff and curator (member of the group Moderator) allows this user to change the color associated to each global response.
A staff *LiveSettingEditor*
Defining a user as staff and member of the group LiveSettingEditor allows this user to alter values stored in the live_settings. Here are the variables stored, and editable:
* | ``number_of_recent_data_source``
| The number of data source to show in the homepage, by default 4 are rendered.
* | ``enable_meta_analysis``
| Render two button at the end of the homepage with allows to either show or download all the responses (that we can see) associated with identified virus and hosts.
* | ``log_entry_up_to``
| Summary of changes are periodically sent (see :ref:`here <email-changes-label>` for details). We store in ``log_entry_up_to`` the primary key of the last event(change, deletion) for which the email have been sent. Changing this variable can make some event not notified, or re-notified.
Account creation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Account creation is normally a task you do not have to do. When a user starts its account creation, the account is created but disabled, and is member of the group ``PendingAccountUser``. The user receive an email in its mailbox with a link. Following this link will enable the account and remove the account from the group ``PendingAccountUser``.
If you want to create an account for someone else, we recommend you to create the account from the admin interface, define a random password that you immediately forget, and ask the user to `reset its password <https://viralhostrangedb.pasteur.cloud/accounts/password_reset/>`_. This use case is useful when you want to grant permission to a user on a data source when (s)he does not have yet account in ViralHostRangeDB.
