Intitulé des groupes

[Rene33]

Bonjour,

En passant à la version 1.5, je viens de remarquer un changement dans l'affichage de l'intitulé des groupes.
Nous avions une équipe "Nous" qui reprend tous les utilisateurs salariés chez nous (3 personnes...). Dans les contacts, sociétés, etc. nous notions comme propriétaire l'équipe "Nous" de manière à ce que le contact (société...) ne soit pas à une personne en particulier.
Au passage en 1.5, apparemment l'équipe s'affiche comme une personne, avec nom, prénom, ce qui fait que dans l'intitulé "propriétaire" on voit N/A N au lieu de "Nous". J'ai rajouté le "prénom" à l'équipe, mais maintenant on a "Nous N"...
Ce n'est pas très grave, mais est-ce normal, et peut-on le changer ?
Et peut-on avoir par défaut l'équipe comme propriétaire, à la place de soi-même quand on crée une nouvelle entité ?

Merci

[genglert]

Ce n'est pas très grave, mais est-ce normal, et peut-on le changer ?

Non ce n'est pas normal. Avec Creme1.5, les Users et les Contacts associés reste synchronisés au niveau des champs nom/prénom/email (dans les versions précédentes il pouvait y avoir des valeurs différentes lorsqu'on modifiait la fiche Contact). En revanche, un User équipe ne devrait jamais être associé à un Contact.
Suite à votre message, j'ai regardé la migration qui synchronise les Users/Contacts existants (au cas où ils divergeraient comme je le disais), et il y a effectivement un bug dedans, puisqu'elle créé un Contact associé lorsqu'il n'y en a pas (ce qui est bien), mais même pour les équipes (ce qui n'est pas bien).

Dans la 1.5.4, je vais donc modifier la migration buggée (pour les gens n'ayant pas encore migré), et faire une migration qui corrigera les migrations foireuses déjà faites : mettre le champ 'is_user' de ce Contact inutile à NULL (plus de lien avec le User), et vidage des champs first_name/last_name/email du User équipe. Le contact inutile ne sera pas supprimé, au cas il aurait été utilisé, et sa suppression sera à la charge des utilisateurs.

Soit vous attendez que je release la 1.5.4 (et que j'ai donc un minimum testé le remède que je vous donne) soit vous le faites à la main en base (c'est assez peu risqué mais bon...).

Et peut-on avoir par défaut l'équipe comme propriétaire, à la place de soi-même quand on crée une nouvelle entité ?

Non.

En revanche j'ai une question : est-ce que tous vos utilisateurs Creme appartiennent à une et une seule équipe, ou bien y a-t-il des utilisateurs qui n'appartiendraient pas à l'équipe dont vous me parlez ? (parce que dans le 1er cas, l'utilisation d'équipe n'aurait au final aucun intérêt).

Merci pour vos retours.

[Rene33]

Bonjour,

Merci pour votre réponse. Désolé de ne pas être revenu plus vite.
J'ai fait la modification sous phpmyadmin, et le problème est réglé.
Pour répondre à votre question, pour le moment tout le monde est dans la même équipe (nous sommes 3). Mais j'ai créé l'équipe pour quand nous grandirons et surtout pour partager l'information.
L'idée que j'ai c'est qu'en mettant l'équipe comme propriétaire d'une fiche (ou comme utilisateur à informer d'une activité) cela permet à tout le monde dans l'équipe d'avoir accès à cette fiche.
C'est pour cela que je vous demandais si l'on pouvait mettre l'équipe comme propriétaire par défaut.
Mais si je n'ai pas d'équipe, comment se fera le partage de l'information entre les utilisateurs ? (je n'ai peut-être pas compris la notion de rôle...)

[genglert]

Mais si je n'ai pas d'équipe, comment se fera le partage de l'information entre les utilisateurs ?

Tout dépend de ce que vous appelez 'partage' :

1. Partage total : tout le monde peut tout voire/modifier/supprimer. Il suffit que vos utilisateurs soient super-utilisateurs.
   
2. Partage partiel : les utilisateurs ne peuvent pas tout voir/modifier/supprimer. Ex : une fiche visible par un utilisateur ne l'est pas forcément pour un autre. C'est la qu'intervient la notion de rôle (et d'équipe suivant les besoins).

(on peut évidemment mélanger super-utilisateurs et utilisateurs 'normaux')


Rôles

Lorsque vous créez un utilisateur 'normal', il faut au préalable avoir créé son rôle. Lorsque vous créez un rôle, vous définissez :

• À quelle application ('Comptes & contacts', 'Facturation'...) ce rôle a droit (et par là j'entends les utilisateurs associés à ce rôle bien sûr) . Les applications auxquelles il a droit apparaissent dans le menu gauche (essayer atteindre une url non permise lui renverra une erreur 403 classique).
  
• Quelles applications les utilisateurs associés peuvent configurer. Ex: pouvoir configurer 'Comptes & contacts' permet de créer de nouveau Secteur d'activités (que l'on trouve dans les Contacts & Sociétés).
  
• Quels sont les types de fiches (Contact, Sociétés, Devis...) que le rôle peut créer.
  
• Quels sont les types de fiches que le rôle peut exporter (via les vues en liste).
  
• Quels sont les droits sur les fiches pour un utilisateur ayant ce rôle :
  • Peut-il voir (ou modifier ou supprimer) les fiches de manière générale (quel que soit leur propriétaire).
    
  • Pareil mais sur les fiches lui appartenant. Notez que les fiches lui appartenant sont un sous-ensemble de toutes les fiches ; donc si vous ne précisez pas de règles pour les propres fiches, mais qu'il y en a une pour toutes, cette dernière s'appliquera sur les fiches lui appartenant.
    
  • Pour les 2 points précédents, on peut préciser un type de fiche en particulier.

Équipe

Cette fonctionnalité est un peu cryptique et mérite donc des explications.

Les équipes viennent en complément des rôles dans certaines situations ; lorsqu'une fiche appartient à une équipe, pour chacun des membres de cette équipe, c'est comme si cette fiche leur appartenait (donc ce sont les droits sur ses propres fiches qui s'appliquent).

Exemple:
Imaginons un rôle 'R1' qui permet l'accès à "Comptes & contact", de créer de nouveau Contact, et de voir et modifier ses propres fiches Contact (et donc pas les autres fiches Contacts, et encore moins les autres types de fiche). Vous voulez que les utilisateurs A & B, qui ont le rôle R1, puissent partager (voir & modifier) certaines de leurs fiches Contact avec l'autre utilisateur, sans pour autant avoir à leur donner les droits sur les fiches de tout le monde. Il suffit alors de créer une équipe E1 qui comprend A & B, et qu'ils assignent les fiches à partager à E1 (plutôt qu'à eux-mêmes).

Remarquez que rien n'empêche un utilisateur d'appartenir à plusieurs équipes.

Quelques conséquences

• Mettre un super-utilisateur dans un équipe n'a évidemment aucune conséquence en terme de droits ; ça permet au mieux un marquage sémantique.
  
• Mettre tous ses utilisateurs dans une seule équipe et assigner toutes les fiches à cette équipe, ça revient au final à transformer les règles 'Ses propres fiches' en règles 'Toutes les fiches' (puisque c'est comme si toutes les fiches appartenait à tout le monde).

[Rene33]

Bonjour,

Merci pour ces explications très claires.
Je comprends donc que ma gestion de l'équipe est superflue, puisque j'avais créé un rôle qui permettait aux personnes qui ont ce rôle de voir et modifier toutes les fiches.
Donc dans la configuration que j'ai mise en place, la notion d'équipe n'a effectivement que peu d'intérêt. Peut-être un jour quand nous serons plus nombreux...
J'espère que les explications sur les notions de rôle et d'équipe seront utiles à d'autres.