User Permissions (especially for web users)

Is there an existing way to have multiple users levels for front-end web users? An example would be showing some extra buttons on a form for "admin" users of a web application.

For example, a "regular" user could submit a form and view the results, but an "admin" user might see an "edit" button to change the contents of the submission. This might be handy for editing a review for example for foul language.

I would imagine that this would be coded into the app in question. Add a field to the $_SESSION upon login if it's the app's admin login, and take it from there. Or even have a separate table in the database for the app to handle logins for that app. I've done that with no problem. I don't see how the main user tables could be designed to cater to every possible use case, unless you changed the user_attributes tables to be more generic, like the system_settings table is, and moved vital data (such as full name and email) into the basic users tables.

I think a more generic login/permissionns system is actually the appropriate track to take. We can then create a "user address book" plugin that can be more easily customized to specific installs. I think it would be impossible to get it 100% right for even the majority of needs, and this would provide an appropriate way to better accomodate that. It also might make it more "sensible" when it comes to using alternate authentication systems, like LDAP and so on.

So the user attributes or profile table would simply take the form of user_id, attribute, value? And be handled much the same as the system_settings are handled? The main difference would be using the user's ID as taken from the main users tables to get the user's attributes. Then anybody could create any kind of profile he wanted, from a simple permission attribute to a dating site's personal profile.

Is there an existing way to have multiple users levels for front-end web users? An example would be showing some extra buttons on a form for "admin" users of a web application.

For example, a "regular" user could submit a form and view the results, but an "admin" user might see an "edit" button to change the contents of the submission. This might be handy for editing a review for example for foul language.

Hi,

Applications of this kinda can easily check the users level by checking to see it the user is a member of a priviledged group. Use the $modx->isMemberOfWebGroup() function.

e.g. create two groups:
1) MyAppAdmins
2) MyAppUsers

Now create the users and assign them to the appropriate group. From the snippet, plugin, etc use the isMemberOfWebGroup() function

if ($modx->isMemberOfWebGroup(array("MyAppAdmins")) {
// do admin stuff here
}
else if ($modx->isMemberOfWebGroup(array("MyAppUsers")) {
// do regular user stuff here
}

Note: In the future we can opimize this function to do more stuff

Thanks Susan and Raymond. And for my next questions, adding "sub-users" to an account not via the Manager. This would be for a subscription site where a company might have a master account and 3-5 unique logins per account. What's the best way to handle that today?

Thanks Susan and Raymond. And for my next questions, adding "sub-users" to an account not via the Manager. This would be for a subscription site where a company might have a master account and 3-5 unique logins per account. What's the best way to handle that today?

Sub-users are just users of a group. Perhaps they are members of two groups, one that designates their membership in the subscription service and another that further organizes them into a particular account. Group and sub-group administration can easily be accomplished with this model, and this brings you the most flexibility in making use of these groups. You could of course make use of this now, and we could work on adding the sub-grouping capabilities for instances where we might need to identify roles the users are playing within a group (e.g. admin, moderator, plain-old user, etc.)

And the user-address-book or user-profile capabilities you guys are looking for will be the first step in the object abstraction work I'd like to work into this project. In other words, the way in which we abstract the API for working with users will become a pattern for abstracting any other objects we use within the system, core or user-defined.

Some other important features of this user-profile system will be to allow chainable, pluggable data for credentials (e.g. authentication) and profile data separately. So a designer could set LDAP to be the credentials provider and define a custom user repository provider that's been storing user data for 10 years to provide the profile information, all through our simple and convenient user API.

SAML support should also be considered in this, as this is an emerging industry standard for handling cross-technology single sign-on and user identity management, using XML.