Data Access Request
Application Form
The web application form can be specified both in terms of schema and UI definition. See Schema Form documentation for more details.
The Preview and Model tabs are informational only and can be used to respectively preview the rendered form and the input data that will be collected.
Properties
Title Field |
Specifies the field which value will be used as the project’s title. |
Summary Field |
Specifies the field which value will be used as the project’s summary. |
End Date Field |
Specifies the field which value will be used to build the project timeline, with an effect on the intermediate and final report notifications. |
PDF Download
The data collected in the form can be downloaded in the following formats:
PDF Template, this option requires uploading a template (one for each configured languages) compatible with the custom Schema Form model.
Printable Page, this option renders the form as a printable page in the browser so the user can either save the form as a PDF or send it to a printer.
Preliminary Form
Same as the Application Form, it uses Schema Form to define the schema and UI definition.
Feasibility Form
Same as the Application Form, it uses Schema Form to define the schema and UI definition.
Amendment Form
Same as the Application Form, it uses Schema Form to define the schema and UI definition.
Under the Properties section one can specify the document’s Title Field and it’s Summary Field as defined in the custom Schema Form.
End User Agreement Form
Same as the Application Form, it uses Schema Form to define the schema and UI definition.
Notifications
Email notifications can be sent, if configured, to applicant and data access officers when an event happens on the data access request. Events can be: status changes, comment additions, or updates. Report notifications can also be configured.
These configurations apply to the data access request as a whole, the main application form, the feasibility forms and the amendments.
Settings
The data access request goes through several steps. Some minimum settings can be applied to control this workflow, i.e. enabling the review status and making the accepted and rejected status final. Also the pattern to generate identifiers for data access requests can be configured.
General
Permissions
By default the Data Access Officers (DAOs) do not have the permission to edit the application forms, only the applicant and the administrator can do it. It is possible to set the edit permission for DAOs.
Other Forms
Other forms within a data access request can be enabled:
Amendments, is the capability of requesting amendments to an approved data access request. This option is disabled by default.
Feasibility inquiries, is the possibility, at any time of the request lifecycle, to ask for a quick evaluation of a project application or amendment. This option is disabled by default.
Variables
It is possible to attach a set of variables to a form (main, amendment or feasibility forms). This set of variables can be defined by the data access request applicant while browsing the catalog of variables, or searching for variables: the variables of interest can be set in a cart which can then be associated to a data access request. Once the request is submitted, the set of variables cannot be modified.
Workflow
The data access request lifecycle can be adjusted with different options:
Under review intermediate state
Conditionally approved intermediate state
Approved final state
Rejected final state
See Data Access Requests Management documentation for details.
ID Generation
Rules for generating a data access request unique identifier can be defined:
ID prefix
ID length, including leading zeros or not
Predefined Action Names
Predefined Action Names are common actions that data access officers perform while processing the data access requests. These actions can then be logged in the data access request history section.
The action names defined here are in fact translation keys that must be created in Translations.
The following steps demonstrate how these names are added:
add the action names without any spaces or any of these invalid characters:
. ~ !
save the configuration
add the action keys in Translations
Note
An action key is the action name preceded by its translation path: data-access-request.action-log.config.label.<action-name>
.
Permissions
Role |
Description |
---|---|
Reader |
Can view all data access request and their amendments. |
There are also two additional (sub) permissions that can be granted to a Reader:
Apply the same permission to associated action logs |
This permission grants viewing the action logs. |
Give access to the private comments section |
This permission grants viewing and editing of private comments. |
Customizing Reports
Warning
This is an experimental functionality, make sure to backup your database beforehand.
Follow these steps to customize the data access request and amendment reports:
stop Mica server
get the current report configuration files as templates:
mongo mica --eval 'db.dataAccessForm.find({}, {csvExportFormat: 1, _id: 0})' mongo mica --eval 'db.dataAccessAmendmentForm.find({}, {csvExportFormat: 1, _id: 0})'
make sure
/etc/mica2/config/data-access-form/
and/etc/mica2/config/data-access-amendment-form/
directories existcopy your templates
export-csv-schema.json
under the previously created directoriesclear the csvExportFormat field in dataAccessForm and dataAccessAmendmentForm:
mongo mica --eval 'db.dataAccessForm.update({_id: "default"}, {$set: {csvExportFormat: ""}})' mongo mica --eval 'db.dataAccessAmendmentForm.update({_id: "default"}, {$set: {csvExportFormat: ""}})'
edit your templates:
/etc/mica2/config/data-access-form/export-csv-schema.json
/etc/mica2/config/data-access-amendment-form/export-csv-schema.json
to make sure that these files can be accessed by Mica server run the following shell command:
``sudo chown -R mica:adm /etc/mica2``
start Mica server
The snippet below shows a report configuration file:
{
"headers": {
"title": {
"en": "<Organization> Access Office",
"fr": "<Organisation> Bureau d'accès"
},
"subtitle": {
"en": "Access Requests Report",
"fr": "Rapport sur les demandes d'accès"
},
},
"table": {
"generic.accessRequestId": {
"en": "ACCESS REQUEST ID",
"fr": "ID DE LA DEMANDE D'ACCÈS"
},
"projectTitle": {
"en": "TITLE",
"fr": "TITRE"
},
}
}
Where fields under headers
are fixed (built-in) but their translations can
be modified. Fields under table
can be fully customized (removed, re-ordered, added, etc).
The table
properties can be inferred from the document’s schema. They are
the fields found in the model.
Note
Properties prefixed by generic. are internal and not part of the data access request or amendment form schemas and are considered built-ins. They can be removed, however.