Posted by skizzo on August 20, 2007 at 1:18pm
Jump to:
| Project: | Account Types |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I used to have a Role that is not (and should not be) included in any Account Type.
The role was assigned only to administrative User 1, governing the menu block display.
Following the latest update I realizzed that the role was automatically unassigned,
and I have no way of reassigning it without going through AT and defining a new
type for that single specific role. Is that the intended behaviour? Thank you.
Comments
#1
User 1 should not need any roles whatsoever. User 1 should have access to all Drupal features at all times. This is all per standard Drupal practice. Both account types and roles would be redundant for user 1.
I'm not sure why a role would be unset. Have you assigned user 1 with an account type? Or do you retroactively assign existing users? Perhaps I accidentally assign user 1 an account type, which should not be the case. Regardless, all features of all modules should accommodate user1 as a special case when checking permissions. Which features of which modules are not doing this? You should file issues with those as well.
Does this answer your question?
So let me know if user 1 is being assigned an account type, and I'll make sure I'm making all of the proper accommodations in this module.
#2
Yes, unlimited access for User 1 correctly holds true. I simply used a SU role (given only to User 1) as
a very effective way of controlling menus (e.g.: the "Navigation" block is configured to show
up only for SU role). The SU role was already assigned to User 1 before I defined Account Types.
From what I see, User 1 is treated as any other user, in that its Account Types
and Roles attributes can be set/edited as for any other user. Maybe it
should simply be disregarded in the context of Account Types. Thank you.
#3
I would beg to argue that it should always be ignored since user 1 has full access to all things at all times. In fact, the role assignment should be removed from the user_edit page for user 1 in my opinion. It just doesn't make sense. I'll mark this as fixed, okay?
#4
Okay. I will test my setup against
the next Account Types update.
#5
I realized I didn't address your specific case listed in #2 above.
Since user 1 has access to all things, even if you setup a role-based menu as it seems you did, and then don't assign the role to anyone, user 1 should still have access to that menu. This follows what I said above.
#6
I checked versions 1.2 and 1.x-dev but I still
see the Account types radio buttons in /user/1/edit
(I would expect to see only the Roles checkboxes)
I am not sure if you are still working on it, if that is
the case please disregard this message. Thanks.
#7
Um, see this other issue: http://drupal.org/node/168943
If you have the 'administer user' permission, it lets you see the user's edit page. If you have the 'administer access control' permission, it lets you see the role checkboxes and also the account type radio buttons. Previously, just the 'administer user' permission was showing the account types radio buttons. I assume that if a person is given access to change roles that they are okay to change account types as well. The idea is only to prevent ACCIDENTAL assigning of a role that shouldn't belong. So some training may be required for the employee that has been delegated to.
Does that make sense?
#8
agreed...
Thank you.
#9