Anubis is a web-based system to handle calls, proposal submission, reviews, decisions and grant dossiers. It allows:
A call for proposals, with a description, optional files attached, and open and close dates. It is a container for proposals, reviews, decisions and grants. The input fields of these entities are created and defined within their call.
A call is open when its
opens date has passed, but its
closes date as not.
A call that does not have both of these values set is not published. This means
that there can be no open call without a
A proposal can be created only within an open call. A user has to create an account in order to create and write a proposal. The proposal must be submitted by the user before the close date of the call.
A proposal is visible only to its creator, the admin, and those accounts that the proposal owner has explicitly given access to.
The reviews of proposals within a call are set up by the admin. This entails defining what information the reviewers must provide, including scores, rank or comments. The admin must then create the actual review form for each reviewer and proposal.
The reviews are visible only the admin, the owner of the call, and optionally by the other reviewers in the call.
The purpose of the decision entity is to document what the result of the review of a proposal is. Creating a decision does not send any email to the proposal author. This has to be done outside of the system.
A grant dossier is a means for the grantee and staff to share information and/or documents about a successful proposal.
A user account is the representation of a user in the Anubis system. A person must have a user account to be able to write a proposal.
There are a few different roles for user account, which give different levels of privileges in the web interface. A user account has one and only one role.
The number of your unfinalized reviews is displayed on a yellow background in the top menu. If there is no such yellow marker, your reviews are done.
The admin is a user account which has full privileges for the Anubis site. She may perform all operations that are possible to do via the web interface.
The source code is available the Anubis GitHub repo.
Anubis requires Python >= 3.9 and CouchDB >= 2.3.1; installation of those systems is not documented here.
Get the source code by downloading the
latest release from GitHub
and unpacking it. For simplicity, rename the top directory to
It is recommended to set up a virtual environment for Anubis. On my
development machine, I am using the
$ mkvirtualenv Anubis $ cd Anubis $ add2virtualenv # To add the top Anubis dir to Python path. $ setvirtualenvproject # To make this dir the default when doing 'workon'.
The installation of a virtual environment system is not documented here.
Within the virtual environment, download and install the required Python packages from PyPi:
$ workon Anubis # Activate the virtual environment $ pip install -r requirements.txt
A Docker container of the latest release is available at GitHub.
The Anubis system relies on the CouchDB database system. This has to be installed and running.
A user account has to be created in the CouchDB system with sufficient privileges to create a database within it. This is the account used by Anubis to create, access and modify its data.
For these actions, refer to the CouchDB documentation.
flask app needs to be run within another web server. This
depends on the web server you select and is not documented here.
In order to execute, there are some configuration that needs to be done at the system level. This can be done in one of two ways:
settings.jsoncontaining the configuration values. or runs as a
uwsgiweb server. It needs to be configured. This is done in a JSON file called
settings.jsonlocated in the
$ cd Anubis $ cp -r site_template site $ cd site $ chmod go-rw settings.json # Since it contains secrets $ emacs settings.json # Ok, ok, vim also works...
In particular, the following settings should be looked at:
"DEBUG": "true"Web server debug mode: should be "false" in production.
"SECRET_KEY": "long-string-of-random-chars"Needed for proper session handling.
"COUCHDB_URL"The URL to the CouchDB instance.
"COUCHDB_DATABASE"The name of the CouchDB database for Anubis.
"COUCHDB_USERNAME"The name of the user account with read/write access to the CouchDB database.
"COUCHDB_PASSWORD"The password for the user account.
"SITE_STATIC_DIRPATH": The full path to the directory containing site-specific files, such as logo image files.
"HOST_LOGO": The file name of the site-specific logo image file. It must be locaded in the
"HOST_NAME": The name of host of the site; e.g. the institution.
"HOST_URL": The URL to the home page of the host.
"MAIL_SERVER": The name of the mail server. There are more settings to define if the mail server cannot be set as
localhost. See the
Place any image files defined in the
settings.json file in the
A database for Anubis needs to be created within the CouchDB instance. See the CouchDB documentation on how to do this.
If a username and password is required for read/write access to the
CouchDB database for Anubis, then add those with the name of the database
settings.json file; see above.
The SciLifeLab instance uses
nginx as a reverse proxy for the
flask web server that implements Anubis. The file
Anubis/install/uwsgi.conf contains the setup for
It should be located in the directory
To run Anubis as a
systemd service under Linux, the file
Anubis/install/anubis.system contains the setup. It should be
located in the directory
systemctl commands are:
$ sudo systemctl status anubis $ sudo systemctl start anubis $ sudo systemctl restart anubis $ sudo systemctl stop anubis
There is also a updating script
be located in a site-dependent directory and run like so:
$ sudo /etc/scripts/deploy_anubis.bash
This script contains the somewhat mysterious commands needed to make things work under the restrictive security policies of SELinux.
Different user roles have different sets of privileges, which determine what they are allowed to do within the Anubis system.
Anonymous users (not logged-in) are allowed to view open calls and not much else.
In order to create and edit anything in Anubis, a user account is required.
The privileges determine which actions are allowed for a logged-in user. The role of the user account controls this. A user account has one single role for the whole system at all times. There are three roles:
Accounts with the user role can be given additional privileges, which relate to specific calls only:
Here's a summary of privileges for some actions. Note that some exceptions are omitted, such as a user explicitly allowing another user to view and/or edit their proposal.
|User||User (reviewer)||User (call creator)||Staff||Admin|
|Create proposal in open call||N/A||N/A|
|Edit a proposal in open call||One's own||Any in call|
|View a proposal||One's own||Any in call||Any in call|
|Create a call|
|Edit a call||One's own|
|Create a review||Any in call|
|Edit a review||One's own||Any in call|
|View a review||One's own||Any in call|
|Create a decision||Only chair||Any in call|
|Edit a decision||Only chair||Any in call|
|View a decision||One's own, when allowed||Only chair||Any in call|
In order to do any work in Anubis, a user must have an account.
Open calls are public, and can be viewed by anyone, including persons who do not have an account.
A user can register an account. Depending on the site policy, the account will be immediately enabled, or an administrator will have to enable the account after inspection. An email will be sent to the user once the account is enabled. It contains information on how to set the password.
A user of the system must register an account, and each user must have a valid email account to which emails with instructions on how to set the password is sent.
Depending on the site configuration, user accounts may be automatically enabled, or require the explicit enabling by the administrator.
The administrator may register accounts, which do not have a valid email address. This can be used for pseudo-user accounts which may be useful in some scenarios.
The administrator may allow a user to create calls. A user who has created a call becomes the administrator of it, and can deal with nearly all aspects of it.
A staff user can read most data in the Anubis system, but can edit only certain data.
An administrator is a user that has privileges to perform any action that is available in the web interface of the Anubis system.
A reviewer is a user account who has been designated as a reviewer in a specific call by the administrator. A reviewer cannot have a proposal of her own in that call.
A user that is a reviewer in one call, is not automatically a reviewer in another call. This makes it possible for a user to be an ordinary submitter of a proposal in one call, while being a reviewer in another call.
A chair is a special kind of reviewer, who has the privilege to create and delete review instances within the call. The chair can also view the reviews of all reviewers in that call.
A call in the Anubis system is a representation of a a call for proposals. It is the basis for all other entities in the Anubis system.
A call has an identifier, a title, and a description. It may have documents attached. It contains the descriptions and definitions for proposals, reviews, decisions and grant dossiers.
A call is prepared and handled by a call owner, which is either an administrator or an account which hase been given this privilege by the administrator. The call owner sets up the input fields for the proposal, and the reviews, the decision and grant dossier for each proposal.
A user with an account in the Anubis system can create a proposal within an open call. The structure of the proposal is determined by the call owner when setting up the call.
A call has an opens date, from which it becomes visible to the world. It has a closes date, which determines the last time a proposal can be submitted in the call.
The opens date of a call defines when the call becomes publicly available so that proposals can be created by users. The call cannot be open unless this has been set.
After the closes date of a call, a user can no longer create, edit or submit a proposal in it.
The input fields for proposals within a call should, of course, be defined before the call is opened. However, it is possible to modify an input field even when the call has been opened. This feature should be used as little as possible since the users writing their proposals may become confused when the their proposal form changes.
A proposal is created within an open call by a user, who must be logged in to an Anubis account. Only one proposal in each call can be created by any given user.
The user fills in the proposal input fields, which are configured in the call by the call owner.
Some input fields may be optional, while some many be required. This is defined when the call owner creates and edits the input fields for the proposals of the call.
An input field has an allowed type of input, such as text, integer, file, etc.
When all required input fields have been filled in with values of the correct type, the user may submit the proposal. A proposal may be un-submitted by the user while the call is open.
If the call has been closed, it is no longer possible to submit a proposal, nor to edit it in any way. The proposal can still be viewed by the user after the call has been closed.
An admin has additional privileges for handling proposals, see Instructions for administrators.
The administrator or review chair can create a decision entity for each proposal. The fields of the decision are configured in the call by the call owner. Thus, a decision may contain more information for the proposer than just the accept/reject decision.
The call owner or the chair of the call may edit and finalize the decision.
The administrator may make the decision for each proposal viewable by the respective submitter by setting an access flag in the call.
Currently, no email is automatically sent by the Anubis system to the submitter when the decision is finalized.
A grant dossier contains information about the grant which is the result of positive decision for the proposal. It may contain information about the grant and documents provided by the grant giver, or by the grantee, for example grant conditions, budget, agreement, and similar.
A grant dossier which has valid values in all required fields is automatically set as complete.
A grant dossier is created by the administrator or staff, who also configure the input fields in it. The proposal owner (which presumably is the grant receiver) can view and edit it.
A review is an evaluation by a reviewer of a specific proposal. The administrator sets up the review of the proposals in a call.
First, the review input fields are configured, in the same way as the input fields for a proposal.
Second, the accounts of the persons who will review the proposals are added as reviewers to the call.
Third, the administrator must also create the review objects (forms) for each proposal for each reviewer. Thus, it is possible to assign a subset of proposals to a reviewer, or all proposals, depending on the policy for that call.
Reviewers cannot create their own review entities; this is done by the administrator. A reviewer can only edit their reviews, not create or delete them.
The review has a deadline, and the reviewers can edit their reviews until that date. The reviews should be finalized to denote that no more work is going to be done on the respective review.
Review instances have input fields defined by the administrator, similar to how a proposal is defined. All reviews within a call have the same input fields.
The proposals of a call must be defined in terms of which data a proposer is supposed to provide. This is configure by the call creator by defining the input fields to be used, their instruction texts and their possible values.
The input fields are the means to store information in proposals, reviews, decisions and grants. They have types which define what kind of information they can store.
All input fields for proposals, etc, can be changed by the call owner, even when the call has been published. This must be done with care, since changing a field may invalidate a proposal, etc, that previously was valid and complete, although the Anubis system should be able to tolerate this. The data for fields that are removed or modified may become unreachable.
All input field types have a number of settings that can be set at creation or modified later. These are:
Identifier. The internal name of the field, which must be unique within the form. It must begin with a letter and continue with letters, numbers or underscores.
Title. The name of the field as shown to the user. Defaults to the identifier capitalized.
Required. Is a value required in this field for the form to be valid?
Staff edit. Only the staff may edit the field. The user will see it.
Staff only. Only the staff may edit and view the field. It is not visible to the user.
Banner. The field will be shown in various tables.
Description. The help text displayed for the field. May contain Markdown formatting.
One single line of text, such as a name or title. May contain any text.
One single email address, which must look like a proper email address. However, its actual validity is not checked.
A selection between Yes and No. If it is not required, then also "No value" will be allowed.
A choice among a set of given text values.
Selection values. The values to let the user choose from. Give the values as text where each line is one value.
Multiple choice. Is the user allowed to choose more than one value?
A number that is a whole integer.
Minimum: An optional lower limit for the value given by the user.
Maximum: An optional upper limit for the value given by the user.
A number that may contain fractions, i.e. a decimal point.
Minimum: An optional lower limit for the value given by the user.
Maximum: An optional upper limit for the value given by the user.
A number in the range of integer values defined on setup. The choice of value is presented as a set of buttons, or optionally by input from a slider.
Minimum: The lower limit for the value given by the user.
Maximum: The upper limit for the value given by the user.
A field of type rank is intended for reviews. The reviewer must assign a value to the field of each of her reviews in a call such that the values are unique and consecutive starting from 1, else an error will be flagged.
A field set as banner will produce an extra column named "Ranking factor" (F(x) below) which is computed from all values in finalized reviews in that call. The formula is:
A(i) = total number of ranked proposals for reviewer i R(x,i) = rank for proposal x by reviewer i F(x) = round(decimals(1, 10 * average(all reviewers( (A(i) - R(x, i) + 1) / A(i)) ))))
For a proposal which has been ranked 1 by all reviewers of it, this will produce a ranking factor of 10, which is the maximum. If a reviewer has ranked it at, say, 3, then the ranking factor will become slightly less than 10.
NOTE: This is currently implemented only for reviews; it is not very meaningful for other entities.
A multiline text which may use Markdown formatting.
An attached file.
This field allow the number of a set of input fields to depend on a number that the user must input. For example, if the user has three collaborators and the name, affiliation and email address of these collaborators must be entered.
When the user inputs a number in a repeat field, the system brings up that number of copies of the other fields that have been associated with.
After having defined a repeat field, the other fields that should be repeated need be associated with it. When creating a new field, there will be a select list field to specify whether that field is repeated by a previously defined repeat field.
NOTE: The repeat field is currently implemented only for grant dossiers.