Mise à jour Mars 2022

Le nouveau Back office offre aux Administrateurs clients un outil puissant, souple et global pour créer des utilisateurs et leur attribuer des permissions dans toutes leurs entités. Ces opérations s’organisent autour d’un concept nouveau : les rôles.

 

Table des matières

• Rôles vs. Profils
• Un back office transverse
• Moteur de recherche : évolutions
• Supprimer une demande d'exercice des droits
• Pour très bientôt !

Rôles vs. Profils

Jusqu'à maintenant les autorisations étaient attribuées à travers 6 profils différents. Lorsqu’un client avec plusieurs entités modifiait les autorisations associées à un profil dans une entité, le profil en question restait inchangé dans les autres entités. De même, si ce client ajustait les autorisations d’un utilisateur dans une entité, cela n’impactait pas les autorisations de cet utilisateur dans les autres entités du client.

 

Avec cette nouvelle mise à jour, les permissions sont attribuées à travers des rôles. Comment est-ce qu’un rôle diffère d’un profil ?

• Les rôles introduisent une approche transverse des entités. Si vous êtes un client avec plusieurs entités, et que vous modifiez les permissions associées à un rôle dans une entité, les permissions associées à ce rôle sont mises à jour dans toutes vos autres entités. Autrement dit, un rôle donné aura toujours les mêmes permissions, pour tous les utilisateurs et dans toutes les entités.

• Si au contraire vous voulez ajustez un rôle selon l’entité ou l’utilisateur, l’approche est désormais de créer un nouveau rôle, avec un nom différent. Car il n’y a aucune limite au nombre de rôles que vous pouvez créer.

• Les rôles servent aussi à définir quels utilisateurs auront accès à quelles entités. Le principe est simple : si vous attribuez un rôle à un utilisateur dans une entité, l’utilisateur aura accès à cette entité. Un utilisateur sans rôles dans une entité n’y aura pas accès.

Un back office transverse

Le nouveau back office permet aux Administrateurs clients :

• de créer leurs utilisateurs ;

• de définir les entités auxquelles chaque utilisateur aura accès ;

sans devoir passer par le Customer Success Manager.

Il offre une vision globale de toutes leurs entités, utilisateurs et rôles.

C’est dans le Back office que les Administrateurs clients vont :

• Créer les Utilisateurs

• Créer les Rôles et modifier leurs permissions.

• Attribuer ou retirer les rôles et modifier leurs permissions, dans chaque entité, à travers la page Attribution de rôles.

Migration des profils vers les rôles

Que vont devenir mes profils actuels ?

Ils seront automatiquement transformés en rôles.

Chaque utilisateur qui avait un profil aura désormais un rôle avec les mêmes permissions. Si les permissions par défaut du profil ont été modifiées, vous retrouverez ces permissions modifiées dans le rôle.

Comment seront-ils renommés ?

• Pour les profils qui n’ont pas été modifiés, le rôle gardera le même nom. Exemple : le profil “Administrateur” deviendra un rôle qui s’appelle “Administrateur”.

• Si le profil a été modifié par rapport aux permissions par défaut, le nom de l’entité sera rajouté au nom du rôle. Exemple : le profil “Administrateur” qui avait été modifié dans l’entité A deviendra un rôle nommé “Administrateur - Entité A”.

Que deviennent les modifications de permissions individuelles ?

Si les permissions d’un utilisateur individuel ont été modifiées sur la page Accès des utilisateurs, l’utilisateur retrouvera ces modifications sur la même page (elles ne sont pas intégrées dans ses rôles).

De nouvelles permissions

Avec le système des profils, certains profils avaient des droits “codés en dur”. Par exemple, les profils Administrateur, Référent entité et Référent suppléant avaient en général accès à tous les traitements, sans qu’il y ait de permissions qui permettaient de maîtriser ces droits. Pour les trois autres profils Responsable direction, Responsable de mise en œuvre du traitement et Utilisateur, il fallait les affecter à des divisions pour qu’ils aient accès aux traitements dans ces divisions.

Le nouveau système des rôles est conçu pour vous donner une plus grande maîtrise des droits de tous les utilisateurs. Les rôles n’ont pas de droits “codés en dur”. Chaque droit est attribué explicitement à travers une permission. De ce fait, nous avons dû créer les permissions manquantes.

Nous avons aussi supprimé certaines permissions qui sont devenues obsolètes avec le nouveau Back office.

Le tableau suivant décrit les nouvelles permissions.

FAQ

Je suis revendeur. Est-ce que je dois désormais utiliser le nouveau Back office pour créer les utilisateurs et attribuer les permissions ?

Non, les revendeurs continueront à utiliser leur backend, comme avant.

Dans mon organisation je n’ai qu’une seule entité. Est-ce que le nouveau Back office me concerne aussi ?

Oui, les fonctionnalités sont les mêmes, que vous ayez plusieurs entités ou une seule. Dans votre cas, sur la page “Attribution des rôles”, vous verrez une seule entité.

Nous n’avons pas encore désigné notre Administrateur clients. Que devons nous faire en attendant ?

Merci de contacter votre Customer Success Manager chez DLD.

Moteur de recherche : évolutions

• Les correspondances partielles sont incluses dans les résultats de recherche. La correspondance peut se trouver dans n’importe quelle partie du mot. A partir de 3 caractères.

• Sauvegarder/partager vos recherches, de la même manière que pour les filtres sur la page des traitements. Saisissez le texte recherché, filtrer sur une ou plusieurs entités si vous le souhaitez, et créez un favori ou partager l’URL. Pour en savoir plus, consultez l’article Le moteur de recherche des traitements.

Supprimer une demande d’exercice des droits

Vous pourrez bientôt supprimer une demande d’exercice des droits, peu importe son statut, y compris les demandes archivées.

La nouvelle permission Administrer les demandes sera nécessaire. Et naturellement, une boîte de dialogue de confirmation permettra d'éviter toute suppression intempestive.

Pour très bientôt !

Droits étendus pour les rédacteurs de traitements

Afin d’offrir une plus grande flexibilité dans le workflow des traitements, les droits des rédacteurs ont été étendus :

• Actuellement : Un rédacteur ne peut pas modifier un traitement une fois qu’il est en cours de revue. Seuls les validateurs le peuvent.

• Bientôt : Les rédacteurs auront accès au bouton Revoir, qui leur permettra de demander la revue d’un traitement. Ils pourront aussi effectuer la revue (c’est à dire modifier le traitement) et soumettre la revue pour validation. Les droits des validateurs resteront inchangés.