Utilisateurs et rôle
#1
Bonjour,

Je suis toujours dans l'adaptation de Creme à mes besoins spécifiques, j'ai d'ailleurs quasiment terminé.

Par contre, je viens de m'apercevoir que lorsque je crée un utilisateur et que je lui attribue le rôle Utilisateur — j'en ai créé 2, "Administrateur" et "Utilisateur" — je ne peux pas entrer sur Creme avec ses identifiants. D'où cela peut-il venir ? Si je passe cet utilisateur en Administrateur, ça fonctionne bien.

Voici les paramètres pour le rôle Utilisateur :
  • Ressources créables : Activités, Contact, Organisations, Document, Ticket ;
  • Ressources exportables : Activités, Contact, Organisations, Document ;
  • Applications autorisées : Activités, Contact, Organisations, Document, Ticket, Configuration générale, Cœur ;
  • Applications administrées : Activités, Contact, Organisations, Configuration générale, Cœur ;

J'ai essayé de jouer avec différentes combinaisons, notamment avec Cœur et Configuration générale mais sans succès.

À l'identification, une erreur 500 est retournée avec le message suivant :
Code :
ContentType matching query does not exist
Ça renvoit apparemment à la ligne 104 de /creme_core/models/auth.py (can_create ct = ContentType.objects.get_by_natural_key(app_name, model_name))

Merci d'avance pour votre aide.
  Répondre
#2
Lorsque l'utilisateur est administrateur, une majorité du code de la gestion des droits n'est pas exécuté (le code renvoie le plus vite possible "OK", vu qu'un administrateur a tous les droits) : ceci explique pourquoi votre problème n’apparaît que lorsque vous être un utilisateur basique.

En revanche vous aurez beau modifier votre configuration, aucune n'est censée aboutir à une erreur 500 bien évidemment. Il semble au vu du peu d'information que vous donnez qu'il y a un gros problème avec votre table des ContentTypes. Avec la valeur des paramètres "app_name" et "model_name" fautifs il serait peut être possible d'émettre un diagnostic. Il serait intéressant de savoir comment vous êtes arrivé à cette situation pour savoir s'ils s'agit d'un bug de Creme, un bug dans votre code, une erreur de manipulation de la base...
  Répondre
#3
Je viens de refaire une installation complète de la version 1.4 alpha (dev). D'autres petits dysfonctionnements apparaissent.

Voilà ce que j'observe :
  • lors de la migration initiale, il attribue bien (apparemment) l'administrateur ('jerome' créé lors du syncdb) au contact Creme Fulbert ;
  • mais lorsqu'on veut créer tout de suite un autre contact, la ligne Utilisateur propriétaire est vide (menu déroulant sans aucun choix), or ce champ est obligatoire. L'attribution au contact 'Fulbert' ne semble au final pas avoir marché ;
  • j'ai ensuite créé un nouveau rôle 'Utilisateur' avec les ressources créables et exportables Contacts, Sociétés et Activités, les applications autorisées Comptes et contacts, Activités, Cœur et Config. générale et administrées Comptes et contacts et Activités ;
  • je crée un nouvel utilisateur administrateur ('admin' sans lui attribuer de contact existant) ;
  • quand je reviens sur la création d'un contact, l'utilisateur propriétaire proposé est le nouvel administrateur 'admin' ;
  • enfin, quand je me connecte sur le nouveau compte ('admin'), je peux créer un nouveau contact et l'utilisateur propriétaire est le bon (mais le même que via l'administrateur 'jerome', ce n'est plus très clair) ;
  • par contre, maintenant, la création d'un nouvel utilisateur avec le rôle 'Utilisateur' fonctionne bien, l'erreur 500 renvoyée sur ma configuration précédente vient bien de mes changements.
  Répondre
#4
Citation :Mais lorsqu'on veut créer tout de suite un autre contact, la ligne Utilisateur propriétaire est vide (menu déroulant sans aucun choix), or ce champ est obligatoire. L'attribution au contact 'Fulbert' ne semble au final pas avoir marché ;

Oui il y a un bug actuellement dans la version de développement. Nous avons rajouté une nouvelle fonctionnalité qui permet d'avoir un nouveau genre d'utilisateur, les utilisateurs "staff". Ces utilisateurs fonctionnent en gros comme des super administrateurs mais qui ne peuvent pas être assignés à des fiches : leur utilité est d'aider les utilisateurs (ou de réparer leurs bêtises : ) ), mais de rester le plus invisible possible. Le bug vient que l'utilisateur créé par le syncdb a son flag is_staff à True ; il devrait être à False, puisque comme vous l'avez vu c'est pénible lorsqu'on n'a que cet utilisateur de ne pouvoir pas l'assigner.

Vous pouvez facilement réparer ce problème en forçant la colonne is_staff à False ; dans un shell django :

Code :
User.objects.filter(pk=1).update(is_staff=False)

Un patch devrait arriver dans le trunk d'ici peu. N'oubliez que la version de développement n'est évidemment pas à conseiller pour une mise en production ; la version finale de la 1.4 devrait arriver courant Février si tout se passe bien.
  Répondre
#5
Merci pour la rapidité et l'efficacité de cette réponse. J'avais effectivement vu l'apparition d'une nouvelle qualité d'utilisateur sans faire le rapprochement avec mon « problème » !
  Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)