Function Level Access Control

[Angel]

Hey Userspice developers,

I just released my project to test and I'm really happy with all the help from userspice. For future versions of userspice, I would like to point out a potential feature that I noticed when I implemented userspice to my project.

Right now userspice controls user's access to the page level, meaning that based on the user's permission level, he/she can either enter a page or not, and there is no third option. But sometimes it would be cool to allow a certain group of user to access the page, and not granting them the permission to do any editing. On the admin's side, when the admin assigns a page to a user group, the admin would be able to do a "edit/read_only" selection for that group.

To generalize this idea, the selection under each page does not necessarily need to be limited to "edit/read_only". Maybe it would be possible to list the features on each page as a multiple-selection dropdown box, so that the admin can specify the user's permission to function level.

One way that I can think of to do this would be to create a separate table in the database called "page_function_matches" for the developers to fill out the functions they have on each of their pages, and then in userspice, the admission_permission.php page reads through the table to list all functions under each page, so that the admin user can choose functions they want to be available for each user group. In the developer's pages side, the developers would add a user group info detection logic at the beginning of their page.php file. If the usergroup info comes with the desired function id, then the page would enable that particular function.

That's just one way to do it that I'm currently using for my project. I'm not a computer science person so I don't know if this is a good method or not. I'm sure you guys would have a much better idea to do this. Please let me know of any questions.

Thanks
Angel

[brian]

I think I'm still having trouble wrapping my head around what someone would edit or leave read only, or whatever. Is this in the context of a web app, let's say, like a photo gallery where people would be able to see a page, but not make changes to the captions or something like that?

Can you give a more concrete example from your use cases?

[Angel]

sure, sorry for the confusion. I think you get it correct. For a photo gallery page, some user would be able to change the caption, or even change the photos, while others would only view the page.

As to user cases in my project, I'm implementing userspice in a production management tool. Let's say there are three types of users, production administrator, production engineer, and operators. They all should be able to see Production_Management_Page_1.php, but the administrators should be able to edit everything on this page, while production engineers should be able to adjust parameters related to their work area only. And the operators should only be able to read the data, without making any changes to the production parameters.

[Angel]

and yes, this is a web app

[brian]

How would this be different from using the existing permissions system, and when an operator arrives, for example, you mark the input fields as read only?

Are you using form fields to present the data or tables or...?

[Steve_Dickson]

Hi Brian,

If I could just elaborate on what Angel 'might' be getting at.. or might not…... In my case, I will be integrating a number of different 'packages' - with userspice at the centre of it all. These include, but are not limited to, QA Reporting System, Ticketing System, Accounting

They all first involve linking the user to a company, so you might have 3 or 10 users linked to one company, e.g.

General Manager: Full access all functions of all three modules. Can see all Tickets raised for the entire company.
Q.A. Manager: Access to Q.A. System only. Can see all Tickets raised for the company.
Production Manager: Access to Ticketing System and Q.A. System. Can see all Tickets raised for the company.
Maintenance Manager: Access to Ticketing System Only. Can only see tickets created by him/herself.
Accounts Manager: Access to Accounting System and Ticketing System
Accounts Clerk: Access to Accounting System and Read-Only Access to all tickets for the company

This is not a great example, but it might give you an idea. Yes it could be done with the existing structure, however there would be MANY user levels and it would get VERY confusing assigning the correct user level - especially the more modules you bring online. One module could be UserSpice itself, whereby you could give a certain user in a company access to modify permissions of users attached to their company!

However, if the user table, had an array of sub-levels, Module 1, Module 2, etc. With each of these 'sub levels', there could be a coding of 0 = No Access, 1 = Read Only, 2 = Edit Capabilities. I guess this would mean, the main user level would simply be referred to as "authorised user", if 0, they can't go anywhere, or down the track it could be 0 = no access, 1 = user with individual access, 2 = user with company access.

Ticketing System (Module 1)
If User Access = 1, and Module 1 status of, 0 = No Access, 1 = Can View, 2 = Can Edit and will only show tickets related to the user.
If User Access = 2, and Module 1 status of, 0 = No Access, 1 = Can View, 2 = Can Edit and will show tickets related to the entire company.

Hope I haven't confused the issue here.

[meetmec12]

Eg if the administrator give a trusted user or team member acsses to some admin page as a moderator with lesser user level . creating users manually without the delete check box . something like that

[mudmin]

You can always use the (poorly named) checkMenu function to hide/show content on the page based on access level, so if you have a regular page you can pop in admin only features by putting in...

Code:

if (checkMenu(2,$user->data()->id)){

Code:

//special admin-only code goes here...

Code:

}

[karmarpgs]

I believe what angel is trying to say or get to is something similar to word press with the Admin, editor, author etc etc with each group having their own permissions..

---

wow, and I just looked at the date on this.. lawd am I behind.. LOL