Desktop Groups
Just a quick note on Desktop Groups. I want to have the ability to assign members to multiple groups.
Say group A, B, etc. will have access to certain modules/apps and features in the desktop. A member can then be assigned to one or multiple groups.
I am trying to decide how to handle the login procedure when a member has been assigned to multiple groups.
- Once member logs in they must select which group they want to be signed in under, and they will only have access to that groups modules/apps and features.
- Once logged in they have access to all modules/apps and features of all the groups they are assigned to, not just one particular group. (I’m leaning toward this one)
I have started on the Db tables for this, but nothing is set. So if anyone has ideas also please share.
December 30th, 2007 at 9:29 pm
I think option number 2 is a better option. Otherwise, as an administrator, I would have to create a separate group for users that need to have apps for all groups they belong to.
I’ll look over your DB a little later and give you some ideas if I have any. Keep up the good work.
December 31st, 2007 at 7:35 am
Number 2 makes more sense to me, that is if you are aiming for companies rather than individuals.
You can then assign an admin the ability to manage packages groups of users have access too.
December 31st, 2007 at 8:01 am
Should be 2 types of applications:
1.available for all
2.available for groups
First one - can add everyone to their desktopconfig (like personal config table - ‘memberconfig’)
Second - can be added if member belongs to that group and can be stored in same personal config table - ‘memberconfig’)
When member belongs to more than one group - add all default modules from each group and that user can select additional modules from list. List created from all available modules for all groups that user belongs to.
If user want to use only modules from one group - in login screen create combobox - select group (all, group A, group B ….)
December 31st, 2007 at 8:36 am
Could you not gain the advantages of both approaches by allowing a member to select from multiple desktops. That is, supporting 2 by default, but supporting 1 by associating multiple desktop_id values with a member_id. Each desktop could support a collection of groups.
January 2nd, 2008 at 3:42 am
Definitely prefer option 2, however I also strongly lean on the requirement to be able to login *post* desktop load, which fits in well with being able to download all the modules on the fly and set all menu/module settings post login.
January 2nd, 2008 at 5:29 pm
I’d prefer option 1.
Option 2 of course gives more ‘power’ but I’ve found that it can cause problems such as someone performing a process they didn’t think they were doing because they thought they were in a different group.
Big ERP systems for example (ie: Oracle) allow a user to have multiple responsibilities (groups) but you must change ‘hats’ (ie: change groups) for different information shown and actions taken. For example, with the ‘payables manager’ responsibility you can see certain screens and perform certain functions but for this person to switch to ‘ar user’ (ie: not manager) they can only do less functions in the ar system.
Less ‘power’ all at once (and as a developer I understand wanting option 2) but as a business, I’d prefer option 1 for safety and data security.
January 5th, 2008 at 10:22 am
Adding support for authentication and authorization are areas where different developers are going to want or need different solutions based on the immediate needs of a project. They usually prefer to handle this on their own based on personal preferences or based on guidelines set by project requirements or customer guidelines.
So, it might make sense to add some abstraction via a desktop auth interface with support for plugins. That is, write a low level generic interface(s) for the desktop, then write plugins to handle the business logic which could vary widely. I noticed one request on the forum thread by fanckxx who suggests the need for this sort of thing. Creating such a beast is probably going to require a lot of brainstorming and experimentation.
The other reason for providing abstraction is support for multiple programming languages if this desktop environment is going to be expanded to support more than PHP (maybe another blog post to clarify this). If it remains in the realm of PHP, a server side solution such as the ACL library for the Zend Framework might be an option eliminating much of this work.
January 9th, 2008 at 4:09 am
I can see the validity of both. Perhaps allowing a group to be exclusive would be a valid option. However I would most likely use option 2.