Permissions in the repository

It’s possible to define permissions on a content (for example, a folder or a document). For that purpose, place the cursor on the folder or the document line and click on « More » and then on « Manage permissions ».

A permission is defined by:

A group of users or a user (to search a group or a user, write the first letters of its name);

A role: > Consumer: can consult content; > Editor: can edit content; > Contributor: can add and edit his documents; > Collaborator: can add and edit his documents and other users documents; > * Manager: can delete content of other user, add rules etc.

Rights matrix details:

https://docs.alfresco.com/content-services/latest/using/permissions/

A folder can inherit permissions defined on its parent folder.

Fields permissions

beCPG restricts access to certain fields of the model per group of users. For this purpose, go to Repository> System> Security rules and create a new entity. This entity corresponds to a group of permissions applied to a beCPG node type. Once the entity is created, edit its properties and choose the node type for which the permission is activated :

Here, permissions are created on the node type « Packaging ». To define the rights on properties, click on the « Permissions » list:

Add new permissions to the data list by clicking on « New row »:

Rules are as follow:

If a group has the « Read » permission on a field, others don’t access the field ;
If a group has the « Read and write » permission on a field, others have the « Read » permission on the field ;
By default, a field is accessible in reading and writing mode.

Once all rules have been defined, go to « Administration beCPG » and execute « Reload properties permissions » by clicking on the corresponding button.

Permission on fields: Confidentiality & security rules

Security rules help to manage system rights when they are defined. They apply to all of PLM. You can however define product by product rules with the "Security" aspect. These rules of confidentiality take precedence and are directly associated with the product.

Functioning :

Create a security rule
Identify the rule as a local permission rule by validating the field
Configure your rules (e.g. visibility right for the Composition list)
Add the Security Aspect (sec:securityAspect) on the target entity
Add the rule with the local permissions to the product with the field: "Security rule"

Application of the rules :

Formulation of the product

Example of using the security aspect : Allow or not the visibility of the composition of a semi-finished product by users. They will be able to use the semi-finished but the composition of the latter will not be visible (the composition will not unfold, impossible to carry out a "duplication of children"). Only authorized persons will be able to read and modify the composition of the semi-finished product.

Permissions on reports

It’s possible to define rights on technical sheets so that their consultation and/or their edition is rigorously managed.

For that purpose :

Go to: Repository> System> Reports> Product reports;
Select the folder corresponding to the type of products of which you want to manage the technical sheets (finished product, raw material …);
Place the cursor on the line corresponding to the concerned technical sheet and click on « More » and then on « Manage permissions »;
If the default configuration doesn’t suit you, which means that you don’t want everybody to have the right to consult the technical sheet as a « Consumer », click on « Inherit permissions ». Thus, the logo turns from « Check » sign to « No entry » sign so that you can administrate your own rights.
Click on « Add a user/group » to give rights only to some users or groups on this technical sheet. Once the user or the group selected, give it a rôle (consumer, collaborator etc.);
Click on « Save »;
Finally, place the cursor on the line corresponding to the technical sheet and click on « More » and then on « Update permissions ».

Permissions on projects

beCPG enables to define rights on projects:

Either on folders which specifically contain projects. For that purpose, consult the documentation concerning the permissions on folders, available at:

ADDRESS

Either on individual projects. For this matter:
Go to the folder containing the project in question;
Place the cursor on the line corresponding to the project and click on « More » and then on « Manage permissions »;
If the default configuration doesn’t suit you, which means that you don’t want everybody to have the right to consult the project as a « Consumer », click on « Inherit permissions ». Thus, the logo turns from « Check » sign to « No entry » sign so that you can administrate your own rights ;
Click on « Add a user/group » to give rights only to some users or groups on this project. Once the user or the group selected, give it a rôle (consumer, collaborator etc.);
Click on « Save » ;

N.B : a user or a group of users defined as « Consumer » on a project won’t have the right to add new tasks neither to modify or delete tasks UNLESS they are assigned to these tasks !

Depending of their rights, users won't have the same access. For example, a consumer won't have the right to modify a task if the task is not assigned to him.

However, the user can modified tasks which are assigned to him.

Permissions on folders in the document list

It is possible to define rights on folders contained in the Documents list of entities (e.g. deleting the inheritance of permissions on a folder and then creating specific permissions). Permissions are defined at template level and apply to all entities associated with the template.

Permissions are applied when entities are created, or to existing entities when they are formulated, or when models are synchronized.

When synchronizing templates, folder rights for existing entities are synchronized:

Either folders do not exist: they are created with the associated permissions.
Either the folders exist: if the spelling of the folders is identical, the permissions are updated.

If the entities contain folders different from those present in the model:

either folders are empty: they are simply deleted
or folders are full: they are retained, but automatically inherit the permissions of the parent folder. If bridging rights had been previously determined, they will be deleted.

**N.B.: Subfolders inherit the permissions of the folder in which they are contained.

Permissions on change orders

If you want to create a change order, you need to have the right permissions.

There are 2 different permissions :

beCPG Change orders creators (CreateChangeOrder) : you can create a change order but you can not apply one.
beCPG Change orders managers (ApplyChangeOrder) : you can apply a change order.

beCPG Change orders managers and the administrator are the only ones able to apply a change order.

How to change users permission: see here

Define rules on folders

Rules can be defined on each folder. By rules is meant :

Send an e-mail when content is added/deleted/modified in a folder ;
Set-up a workflow when content is added to a folder ;
...

To define a rule:

Go to the directory containing the folder in which a rule has to be added ;
Click on « More » and then « Manage rules ».

Two cases are possible:

If no rule is associated to the folder, two actions are possible:

Create rules : define rule from nothing on the chosen folder ;
Link to rule set : Reuse an existing set of rules defined for another folder.

If one or more rules are already assciated to the folder, four actions are possible:

Inherit rules: the folder on which we’re working inherits the rules of its parent folder ;
New Rule: creates a new rule.
Run Rules: execute an existing rule ;
Edit: modify an existing rule ;
Delete: delete an existing rule ;

Generalities about the creation of a new rule

By clicking on « New rule », a form appears in order to fill:

The name of the rule (1);
The descripion of the rule (2);
The moment when the action generated by the rule must be executed (3);
The conditions that have to be met (4);
The action to trigger (5);
The action to execute (6).

Note: supplementary options are available (7) :

Disable a rule: desactivate a rule instead of deleting it (because perhaps it could be useful later);

Apply rules to the subfolders : the rule is called « recursive rule ». In that case, conditions have to be well defined, otherwise the performances could be degraded.

Run rule in background

Finally, click on « Create » to register the rule.

Example of a new rule creation allowing the deplacement of products, from a folder A to a folder B, when they pass from the state « Simulation » to the state « Validated ».

"More details": http://docs.alfresco.com/4.1/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Fconcepts%2Flibrary-folder-rules.html

Versions management rules

beCPG proposes a rule to manage the number of versions on a document. This rule manages the legacy.

The action of versions management contains the following configurations :

    Version: Minor,Major,Both;
    Number of versions: all if empty;
    Number of days to conserve: all if empty;
    Number of versions per day: all if empty;

In the case of many versions rules (inherited or not) fields are surcharged. Example :

    Rule 1 on the ECM (Both, 5 versions max)
    Rule 2 on the Site A (Minor, empty)
    Rule 3 on the Site A (Major, 5 versions max, 1 version per day)
    Rule 4 on the Site B (Major, empty)

Which gives for a document in the site A:

    All the minor versions
    5 versions max, 1 version per day for the major versions

Which gives for a document in the site B:

    All the major versions
    5 minor versions Max

The rules application is done when a document is updated or manually. Thus, even if the number maximum of days is 2, if the document is not modified, the versions are preserved. If the rule is modified when the document is updated, the new rule is applied on all the document’s historical versions.

The versions conservation is made in this order:

Major versions are deleted before the minor versions.
When a major version is deleted, all its minor versions are also deleted.
The rules evaluation for the minor versions is made for all the minor versions of each major version.

It begins with the last rule and it goes back to the former one:

Versions are gathered per day;
Day surplus versions are deleted;
Surplus days are deleted;
The remainder is sorted by date and the maximum number of versions is conserved (the most recent versions are conserved).

PERMISSIONS