Plan for Permissions

Jan 12, 2009 at 8:50 PM
I have been slowly adding permissions to dropthings with the goal of making a "business portal" similar to sharepoint, but better. But at the same time with roles disabled the original dropthings would not be affected.
I figure now that it has been adopted by some of the other developers it would be a good time to make a plan for the permission enhancements...

Here is where I tentively thought it was going.
1. Create basic roles that would disable certain widgets based on the role table
2. Create roles that would disable Features of the widgets (such as remove, add, or move)
3. Create roles that would disable page setting changes (adding new tabs)

The first 3 have been completed...
This is where things get a little hazy in my planning
4. Create a user role group similar to windows groups so the user can be added to the group which is associated with several roles.
5. Create a widget role Table so one widget can be associated with multiple roles, instead of the current one-to-one association.

Any other ideas would be appreciated.
Jan 13, 2009 at 11:57 AM
Hi, and thank you for this very usefull feature.

I use dropthings in my project as an intranet IT web portal. I've some topics that I want to implement that are related to groups/permissions you already build. Here some other things that would be usefull on this subject :

- IT operator build dashboard with widgets configured by scripts in the edit mode of the widget. I would like to be able for this IT operator to define a list of people who can access a page in "Visitor" mode (no ability to change widget settings or position).
- Another way to achieve this would be to be able for a "power user" to export a page to asome kind of general profile who can be accessed by a group of visitor.
- last choice is to export the page to the visitor profile. In this case, still no edit in the widgets, but visitor can changes the page layout. (this is really just a brainstorm on what I'm planning)
- I think that for heavy use of group permission, a mapping to a LDAP directory would be the most practical way to manage permission (ex: Active Directory / ADAM / openLDAP...), in this case the dropthings database would do a mapping between credential of the user account in the LDAP directory to effective rights in the portal ? this changes the way dropthings works at this time (cause dropthings is designed for an internet use)
- What about a configuration management that permit to set/define roles on the portal, and manage page permission for other people for "power user" ?

hope this helps, if I have something new I will post my comments here.



May 4, 2009 at 2:07 AM
I would forgo the complexities of exactly "how" the user is authenticated at this point in favor of having the permissions/roles able to be used to manage widget behavior for guests vs. registered users vs. admins.