Project

General

Profile

Bug #210

Problème de droits d'accès formulaire et back-office

Added by Victor Claudet almost 12 years ago. Updated over 9 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
15 October 2010
Due date:
% Done:

100%

Estimated time:
Patch proposed:
Planning:

Description

Sur mon site de démo, j'ai créé un rôle qui a le droit de remplir un formulaire et j'ai créé des utilisateurs qui sont associés à ce rôle.
Ces utilisateurs ont uniquement ce rôle et ne sont associés à aucun autre rôle.
Pourtant quand un utilisateur se logge, il a accès au lien back-office depuis son espace mon compte, alors qu'il n'a les droits en gestion sur aucun formulaire.
Le lien Back-office ne devrait pas apparaitre.


Files

Associated revisions

Revision 1e30bcef (diff)
Added by Thomas Noël over 10 years ago

add an attribute "allows_backoffice_access" on roles

History

#1

Updated by Thomas Noël almost 11 years ago

Ce bogue est toujours vivant ?

#2

Updated by Frédéric Péters (de retour le 10/10) over 10 years ago

Je dirais que oui, vu dans auquo, myspace.ptl:

        if user.is_admin or user.roles:
            profile_links.append('<a href="%sbackoffice/">%s</a>' % (root_url, _('Back office')))

Par contre ce n'est pas follement évident d'automatiquement déterminer quels sont les rôles qui devraient mener à l'ajout de ce lien (ceux apparaissant en destinataire d'un formdef ou apparaissant en "by" d'un item de workflow, c'est un peu lourd à vérifier). Peut-être que le plus simple est alors d'ajouter une case à cocher "accès au backoffice" à la définition d'un rôle.

#3

Updated by Thomas Noël over 10 years ago

Frédéric Péters a écrit :

ajouter une case à cocher "accès au backoffice" à la définition d'un rôle.

Oui (et Victor aussi), même si c'est pas forcément super top, dans un premier temps ça va permettre de répondre à la demande.

La demande classique : avoir des formulaires accessibles uniquement pour un certain type d'utilisateurs (président d'association, commerçant, agent interne, etc.) qui n'auront jamais accès au backoffice.

#4

Updated by Thomas Noël over 10 years ago

  • Target version set to 81
#5

Updated by Frédéric Péters (de retour le 10/10) over 10 years ago

Approuvé à l'eocamp, pas de magie, même pas besoin d'un second temps.

#6

Updated by Frédéric Péters (de retour le 10/10) over 10 years ago

  • Assignee set to Thomas Noël
#7

Updated by Frédéric Péters (de retour le 10/10) over 10 years ago

"Autorisation d'accès au backoffice", case cochée par défaut.

#8

Updated by Thomas Noël over 10 years ago

Actuellement on a ce code :

    def can_go_in_backoffice(self):
        if self.is_admin:
            return True
        from formdef import FormDef
        formdefs = FormDef.select(lambda x: not x.is_disabled())
        for formdef_id in FormDef.keys():
            formdef = FormDef.get(formdef_id, ignore_errors=True)
            if formdef and not formdef.is_disabled() and formdef.receiver_id in (self.roles or []):
                return True
        return False

Je propose de complètement supprimer la detection "j'ai un role qui est destinataire" et de se baser UNIQUEMENT sur un test "j'ai au moins un role qui a accès au backoffice".

Ok avec ça ?

#10

Updated by Thomas Noël over 10 years ago

  • File wcs-roles-can-go-in-backoffice.diff added

Voilà le patch pour w.c.s.

Si ok, je ferai celui pour auquo dans la foulée.

#11

Updated by Frédéric Péters (de retour le 10/10) over 10 years ago

Je ne suis pas fan du nom de l'attribut, trop proche de la méthode du même nom dans la classe User; allows_backoffice_access ?

#13

Updated by Thomas Noël over 10 years ago

  • File deleted (wcs-roles-can-go-in-backoffice.diff)
#14

Updated by Frédéric Péters (de retour le 10/10) over 10 years ago

C'est ok pour moi, go.

#15

Updated by Thomas Noël over 10 years ago

  • Status changed from Nouveau to Résolu (à déployer)
#16

Updated by Thomas Noël over 10 years ago

  • Target version changed from 81 to Au-quotidien 2012.2
#17

Updated by Thomas Noël over 9 years ago

  • Status changed from Résolu (à déployer) to Fermé
#18

Updated by Frédéric Péters (de retour le 10/10) over 9 years ago

  • % Done changed from 0 to 100

Also available in: Atom PDF