Merge branch 'dmp-refactoring' of https://code-repo.d4science.org/MaDgiK-CITE/argos into dmp-refactoring

dmp-frontend/src/app/ui/admin/tenant/editor/tenant-editor.component.html

@@ -44,6 +44,7 @@
 									<input matInput type="text" name="code" [formControl]="formGroup.get('code')" required>
 									<mat-error *ngIf="formGroup.get('code').hasError('backendError')">{{formGroup.get('code').getError('backendError').message}}</mat-error>
 									<mat-error *ngIf="formGroup.get('code').hasError('required')">{{'GENERAL.VALIDATION.REQUIRED' | translate}}</mat-error>
+									<mat-error *ngIf="formGroup.get('code').hasError('pattern')">{{'TENANT-EDITOR.VALIDATION.INVALID-CODE' | translate}}</mat-error>
 								</mat-form-field>
 							</div>
 							<div class="col-12">

dmp-frontend/src/app/ui/admin/tenant/editor/tenant-editor.model.ts

@@ -43,7 +43,7 @@ export class TenantEditorModel extends BaseEditorModel implements TenantPersist
 		const baseValidationArray: Validation[] = new Array<Validation>();
 		baseValidationArray.push({ key: 'id', validators: [BackendErrorValidator(this.validationErrorModel, 'id')] });
 		baseValidationArray.push({ key: 'name', validators: [Validators.required, BackendErrorValidator(this.validationErrorModel, 'name')] });
-		baseValidationArray.push({ key: 'code', validators: [Validators.required, BackendErrorValidator(this.validationErrorModel, 'code')] });
+		baseValidationArray.push({ key: 'code', validators: [Validators.required, Validators.pattern('^[a-z0-9\_\]+$'), BackendErrorValidator(this.validationErrorModel, 'code')] });
 		baseValidationArray.push({ key: 'description', validators: [Validators.required, BackendErrorValidator(this.validationErrorModel, 'description')] });
 		baseValidationArray.push({ key: 'hash', validators: [] });
 

dmp-frontend/src/assets/i18n/en.json

@@ -1369,6 +1369,9 @@
 	},
 	"TENANT-EDITOR": {
 		"NEW": "New Tenant",
+		"VALIDATION": {
+			"INVALID-CODE": "Invalid code"
+		},
 		"FIELDS": {
 			"NAME": "Name",
 			"CODE": "Code",

docs/docs/documentation/administration/introduction.md

@@ -7,10 +7,10 @@ description: Discover all the configuration options available for an administrat
 
 There are a lot of views in the application available only for users that are given elevated privileges. In the pages that follow we will discover all the configuration options available in these views for an administrator, with the most important being the following:
 
-- **Users**: Being able to control the users of the platform.
+- **[Users](/docs/documentation/administration/users)**: Being able to control the users of the platform.
-- **Tenants**: Being able to control the tenants of the platform. Think of tenants as different organisations that can use the application independently at the same time without the need of different deployments.
+- **[Tenants](/docs/documentation/administration/tenants)**: Being able to control the tenants of the platform. Think of tenants as different organisations that can use the application independently at the same time without the need of different deployments.
-- **Notification Templates**: Being able to modify the structure of notifications sent to users based on different events.
+- **[Notification Templates](/docs/documentation/administration/notification-templates)**: Being able to modify the structure of notifications sent to users based on different events.
-- **Languages**: Being able to add support for more languages or modify existing ones.
+- **[Languages](/docs/documentation/administration/languages)**: Being able to add support for more languages or modify existing ones.
-- **Reference Types**: Being able to configure static or external data sources that are made available as autocomplete fields on the forms of the platform.
+- **[Reference Types](/docs/documentation/administration/reference-types)**: Being able to configure static or external data sources that are made available as autocomplete fields on the forms of the platform.
-- **Plan Blueprints**: Being able to control the blueprints available for [plans](/docs/documentation/application/plans).
+- **[Plan Blueprints](/docs/documentation/administration/blueprints)**: Being able to control the blueprints available for [plans](/docs/documentation/application/plans).
-- **Description Templates**: Being able to control the templates available for [descriptions](/docs/documentation/application/descriptions)
+- **[Description Templates](/docs/documentation/administration/templates)**: Being able to control the templates available for [descriptions](/docs/documentation/application/descriptions).

docs/docs/documentation/application/blueprints.md

@@ -3,4 +3,12 @@ sidebar_position: 3
 description: What do we call 'blueprints'
 ---
 
-# Blueprints
+# Blueprints
+
+A blueprint describes how a [plan](/docs/documentation/application/plans) is structured. A plan consists of sections in which there is basic information about the plan overall or the specific section. Also, in the blueprints sections, we can specify the [templates](/docs/documentation/application/templates) of the [descriptions](/docs/documentation/application/descriptions) that can be added to them. It is not mandatory for a section to have description templates attached but there has to be **at least one** section that has.
+
+:::info
+
+The way we create a blueprint is described in detail in the [blueprint administration](/docs/documentation/administration/blueprints) section of the docs.
+
+:::

docs/docs/documentation/application/plans/imports.md

@@ -9,3 +9,5 @@ You can import an existing plan so that you don't have to work on a new one from
 
 ![Import plan popup dialog](https://fakeimg.pl/600x400)
 *Import plan popup dialog*
+
+When the import is completed, you get redirected to the `My Plans` page.

docs/docs/documentation/application/plans/invite-collaborators.md

@@ -13,9 +13,10 @@ Before finalization, the plan can be further edited by inviting users in order t
 ![Invite users](https://fakeimg.pl/600x400)
 *Invite users*
 
-For each member, a role on the plan must be defined. There are three different roles:
+For each member, a role on the plan must be defined. There are four different roles:
 
 - **Owner**: Manage and edit all plan features.
+- **Viewer**: Have only read access.
 - **Description Contributor**: Edit only the descriptions of this plan.
 - **Reviewer**: View the plan without being able to edit it.
 

docs/docs/documentation/application/references.md

@@ -3,4 +3,14 @@ sidebar_position: 2
 description: What do we call 'references'
 ---
 
-# References
+# References
+
+There are a lot of cases where the users have to input their anwser selecting from a list of values which may or may not come from an independent external source. In any case, these options are highly configurable and we call them `references`.
+
+A very good example of a reference is the license of a plan. The license options can either be configured as an internal (*static*) or an external (*API*) source.
+
+:::info
+
+The way we configure a new reference is described in detail in the [reference types administration](/docs/documentation/administration/reference-types) section of the docs.
+
+:::

docs/docs/documentation/application/templates.md

@@ -3,4 +3,12 @@ sidebar_position: 4
 description: What do we call 'templates'
 ---
 
-# Templates
+# Templates
+
+A template dictates the structure of a [description](/docs/documentation/application/descriptions). This means that every description must have a description template attached. It is the most important part of a plan's structure because it contains the sections and the actuall question definitions the end users will have to answer, to complete the [plan](/docs/documentation/application/plans).
+
+:::info
+
+The way we create a template is described in detail in the [template administration](/docs/documentation/administration/templates) section of the docs.
+
+:::