Automating Setting of Permissions

mwweb commented

2017-08-21 20:51:58 +00:00

(Migrated from github.com)

I posted this a while back, but it was closed without discussion, so I'm going to repost it, as I believe that this would be a major improvement to JCB.

I think a great enhancement to JCB would be the "automatic" setting of permissions upon install. This can, from my own experience, be accomplished by a two-step process. Someone might have a better implementation, but this is what worked on my 21 site views.

To extend JCB to support automatic ACL settings:

Add 2 new fields to JCB -> Admin Views -> Permissions repeatable field. 1 field would query and populate from #__viewlevels, the other from #__usergroups.
On compile of the component, the compiler would add to the compile of the permissions already being done. Right now it does similar to {} in the rules field in the assets table, until you go in and manually set every permission and save, which could be extremely frustrating for end users. The code below would set the looks and looking views on the DEMO component to automatically accessible by public on install, and create to registered.

               // $type (install, update or discover_install)
                if ($type == 'install') {
                        $db = JFactory::getDBO();
                        $query = $db->getQuery(true);
                        $query->update($db->quoteName('#__assets'));
                        $defaults = '{"site.looking.access":{"1":1},"site.looks.access":{"1":1},"core.create":{"2":1},"core.delete":{"2":1},"core.edit":{"2":1},"core.edit.state":{"2":1},"core.edit.own":{"2":1},"core.edit.created_by":{"2":1},"core.edit.created":{"2":1},"look.create":{"2":1},"look.delete":{"2":1},"look.edit":{"2":1},"look.edit.add":{"2":1},"look.edit.alias":{"2":1}}'; // JSON format for the parameters, see PHP serialize()
                        $query->set($db->quoteName('rules') . ' = ' . $db->quote($defaults));
                        $query->where($db->quoteName('name') . ' = ' . $db->quote('com_[[[component]]]'));
                        $db->setQuery($query);
                        $db->query();
				}

Any thoughts?

Note: The code above would be generated in the PHP Postflight (install) in script.php.

I posted this a while back, but it was closed without discussion, so I'm going to repost it, as I believe that this would be a major improvement to JCB. I think a great enhancement to JCB would be the "automatic" setting of permissions upon install. This can, from my own experience, be accomplished by a two-step process. Someone might have a better implementation, but this is what worked on my 21 site views. To extend JCB to support automatic ACL settings: 1. Add 2 new fields to JCB -> Admin Views -> Permissions repeatable field. 1 field would query and populate from #__viewlevels, the other from #__usergroups. 2. On compile of the component, the compiler would add to the compile of the permissions already being done. Right now it does similar to {} in the rules field in the assets table, until you go in and manually set every permission and save, which could be extremely frustrating for end users. The code below would set the looks and looking views on the DEMO component to automatically accessible by public on install, and create to registered. ``` // $type (install, update or discover_install) if ($type == 'install') { $db = JFactory::getDBO(); $query = $db->getQuery(true); $query->update($db->quoteName('#__assets')); $defaults = '{"site.looking.access":{"1":1},"site.looks.access":{"1":1},"core.create":{"2":1},"core.delete":{"2":1},"core.edit":{"2":1},"core.edit.state":{"2":1},"core.edit.own":{"2":1},"core.edit.created_by":{"2":1},"core.edit.created":{"2":1},"look.create":{"2":1},"look.delete":{"2":1},"look.edit":{"2":1},"look.edit.add":{"2":1},"look.edit.alias":{"2":1}}'; // JSON format for the parameters, see PHP serialize() $query->set($db->quoteName('rules') . ' = ' . $db->quote($defaults)); $query->where($db->quoteName('name') . ' = ' . $db->quote('com_[[[component]]]')); $db->setQuery($query); $db->query(); } ``` Any thoughts? Note: The code above would be generated in the PHP Postflight (install) in script.php.

Llewellyn commented

2017-08-21 22:46:26 +00:00

The problem we have here is that 99% the public group is ID 1, but it is a movable ID and setting it hard coded in your component could be an issue.

What we did is we added the option to remove permission control on the view, so that it does no have a permissions check. This is not ideal but it is an option, since if the view is set by default to public access, it may not even need access control.

But okay lets say we want to access control in there, and yet start it off as public upon install of the component, witch is the only group we can really target with 99% accuracy. We have two options:

Automatically set all site-views it to public access (always)
Add a switch that tells JCB what view should be public or not set (not public)

To me the second option seems more like the freedom we like to have, yet the first really is the expected way it should have worked... or so it seems.

What do you think.

The problem we have here is that 99% the public group is ID 1, but it is a movable ID and setting it hard coded in your component could be an issue. What we did is we added the option to remove permission control on the view, so that it does no have a permissions check. This is not ideal but it is an option, since if the view is set by default to public access, it may not even need access control. But okay lets say we want to access control in there, and yet start it off as public upon install of the component, witch is the only group we can really target with 99% accuracy. We have two options: 1. Automatically set all site-views it to public access (always) 2. Add a switch that tells JCB what view should be public or not set (not public) To me the second option seems more like the freedom we like to have, yet the first really is the expected way it should have worked... or so it seems. What do you think.

Llewellyn commented

2017-08-21 22:50:24 +00:00

We also will now need to check if a developer has not already added his/her own implementation of this feature... and only if not found add the JCB automated implementation... man this is fun....lol

Llewellyn commented

2017-08-21 23:01:25 +00:00

Don't forget that there is also permissions per fields and back-end views. I have a component here on Github... look at this permission nightmare, and this is a small one. In a learning manager I have so huge a permission structure, I had to make database adjustments to insure the field does not get cut.

So to just target the site permissions is the first step of a very big issue here. I have been thinking about it for months now... how to set the permissions per/field per/view in JCB so that the component on install has a well formed default permissions in place for all groups, and options.

Just can't find a consistent way as yet.

But to start with these site-views seems very important... just though you need to also think about the bigger reality at hand. Maybe you have some thoughts that could help 👍

Don't forget that there is also permissions per fields and back-end views. I have a component here on Github... look at this [permission nightmare](https://github.com/namibia/CBP-Joomla-3-Component/blob/master/admin/access.xml), and this is a small one. In a learning manager I have so huge a permission structure, I had to make database adjustments to insure the field does not get cut. So to just target the site permissions is the first step of a very big issue here. I have been thinking about it for months now... how to set the permissions per/field per/view in JCB so that the component on install has a well formed default permissions in place for all groups, and options. Just can't find a consistent way as yet. But to start with these site-views seems very important... just though you need to also think about the bigger reality at hand. Maybe you have some thoughts that could help :+1:

mwweb commented

2017-08-21 23:01:50 +00:00

(Migrated from github.com)

Going the route that you are suggesting, I would vote for option 2 above (Add a switch). In my own component, I have a site view call Favorites. On one of the item views, I have a button that when clicked added a record to a favorites table with the user id and the item id. The favorites view then displays the items that they have added to their favorites. This favorites site view would never be public, since it's querying for the user id upon loading.

In my suggestion, I was looking at what the majority of components in the JED do. I haven't come across any that you install and have to set all the site views. The site views are being pre-set.

Going the route that you are suggesting, I would vote for option 2 above (Add a switch). In my own component, I have a site view call Favorites. On one of the item views, I have a button that when clicked added a record to a favorites table with the user id and the item id. The favorites view then displays the items that they have added to their favorites. This favorites site view would never be public, since it's querying for the user id upon loading. In my suggestion, I was looking at what the majority of components in the JED do. I haven't come across any that you install and have to set all the site views. The site views are being pre-set.

Llewellyn commented

2017-08-21 23:05:11 +00:00

Okay for a start I will add the second option to JCB in the next release... we take it from there.

mwweb commented

2017-08-21 23:05:13 +00:00

(Migrated from github.com)

I will say that documentation one how to set defaults was very limited out on searches. That's when I finally found the example that I posted, which works 99.9% of the time on my test installs. But, there could be instances where someone deletes the core Joomla! ACL, and adds only their own. I do think that those types will be the "minority".

mwweb commented

2017-08-21 23:05:33 +00:00

(Migrated from github.com)

Maybe @ro-ot will have some suggestions as well.

Llewellyn commented

2017-08-21 23:30:11 +00:00

Joomla in the global options has a "Default Access Level" lets use that to get the default group and then use that ID for the default access level (during install). This should be as good as it will get to identify the public/default access group. Since by default that will be public, yet if someone has change that it means they don't want stuff to default be public, but instead this other group... so they get what they expect, and we can set a notice in case the id is not 1 (the default public group).

Well this is to get a 100% accuracy in setting the site-views permissions.

Joomla in the global options has a "Default Access Level" lets use that to get the default group and then use that ID for the default access level (during install). This should be as good as it will get to identify the public/default access group. Since by default that will be public, yet if someone has change that it means they don't want stuff to default be public, but instead this other group... so they get what they expect, and we can set a notice in case the id is not 1 (the default public group). Well this is to get a 100% accuracy in setting the site-views permissions.

ro-ot commented

2017-08-22 17:03:08 +00:00

(Migrated from github.com)

Far as I know you can't just delete the Public Group ID 1, you can rename it, but not remove it. You can check me on this.

So just use 1 and let the 0.1% deal with their own mess 👍

Far as I know you can't just delete the Public Group ID 1, you can rename it, but not remove it. You can check me on this. So just use 1 and let the 0.1% deal with their own mess :+1:

ro-ot commented

2017-08-22 17:06:09 +00:00

(Migrated from github.com)

About the solution, option 2 sounds about right. Like always @Llewellynvdm is a star 🥇

About the solution, option 2 sounds about right. Like always @Llewellynvdm is a star :1st_place_medal:

😆 1

Llewellyn commented

2017-08-22 22:19:23 +00:00

Okay I have the first part of this issue resolved, we now have site access (default public) switch and implementation in compiler.

Yet how to add the fields and back-end views to this will not be that easy, we will have to spend some more time on this latter. For now please test the pull request... and let me know if it works as expected.

Okay I have the first part of this issue resolved, we now have site access (default public) switch and implementation in compiler. Yet how to add the fields and back-end views to this will not be that easy, we will have to spend some more time on this latter. For now please test the pull request... and let me know if it works as expected.

Llewellyn commented

2017-08-23 16:31:46 +00:00

@mwweb we are waiting for your feedback 👍

@mwweb we are waiting for your feedback :+1:

mwweb commented

2017-08-23 16:43:51 +00:00

(Migrated from github.com)

I will test it today and give my feedback

Automating Setting of Permissions #113