Skip to content

036 Setting Site View Permission

Amigo edited this page Jul 25, 2019 · 21 revisions

SETTING SITE VIEW PERMISSION

00:00:00

How to set the Site View Permission. The site view permission is related to the front end of any site view. Since it is usually by default set to 'Not Allowed', that is because there is the problem where that data is controlled by the Global settings of the component. Unless you write some custom script to add that Global settings to the database for permissions, it does not have those permissions set and because it is not set, it is by default always set to 'Not Allowed'. 00:00:45 Let me explain that on a code level . Sermon Distributor is used which is one of the demo components that is available.(Access to this demo component may be purchased) It has Site views and in the options tab, there is a permission tab.

If a search is done for 'Site'. Categories site access, plural and category site access, singular may be seen. There is also preacher site access and preachers, series and series list, and sermon.00:01:38 All these various site accesses literally indicates whether the public will have access. By default, it is set to inherit, and inherit will show 'Not Allowed'. Now there is something that I have done to try and accommodate this problem in JCB. <<<<<<<<,,

Explanation On The Code Level

  • Default

Let's close out here and look at some of the code I have done there so I will have to go to Component Builder 00:02:12 And then to components. I'll open sermon distributor, I will go to settings, site views. I will click add, you will see that we have heactuallyre a value called default view. What the default view really is, is that view 00:02:45 that the component will direct you to, if you are accessing a view that you as a user don't have access to. Usually we would set the default view to not have an access control. We will say the default view 00:03:12 doesn't have access control. That means it's open and public to all. We could explain on this view how to get access for example to the rest of the component. Because you could see in what user group the user is and you can by that determines some messages. There can only be one default view, even if you select more than one. The first one, the compiler gets to become the default view, the next one will be ignored. 00:03:52 There can only be one at the moment. It says select only one. If you have an access for categories and it's not yet set, it will throw the user back to, for example, to preachers. What is the advantage of this? It simply negates the error page. So did you don't get a loop where the permission never gets resolved. It goes into a loop and then crash the site. This prevents that but it doesn't solve our permission structure of completely. But it is at least a first step towards trying to resolve it. This is your default page. Don't give the default page permission structure if any of the other pages is accessed 00:04:43 it will divert to the default page.

Adding Custom Scripting - Showing After Installation

The next step that we have to try and address this problem, is some custom scripting that you can add which will show after installation. The component where we have this shown is the demo component. You can open the PHP tab. In the PHP tab you will see that it has a queued message 00:05:19 in the post flight installed blocks. It gets the factory, get application. 'First set the component global setting and the permissions in the option area or the front end of the component will not work as expected. Please note that each view on the front end has access and permissions. So if you would like the public to access those views, they must be given the access and permission.' This is an info message that comes up 00:05:54 after you have install. That is another way that we've tried to help the user realize that he needs to add some. You can change this into a link, become very fancy or you could even add custom script here, that updates 00:06:16 this components promotional structure, and adds the public to have access to the site views. These are some of the ways that we are trying to resolve the permission restraints of site views.

Looking Into Code - Site Root

Let's look at the code level. Here we have the access file open of sermon distributor, and if we do a search: site. 00:07:00 You will see that it has the site access values set for the component. When we look at the front end of the component, open categories, you see that here it is asking whether the user has that access, and if it doesn't, it does a redirect, then redirects to the default page. Let's open the default page. 00:07:32 The ideal of the default page, is that if the default page is not the site route, it cannot access the default page. It will add this error, and redirect to the site root, which being the websites homepage. That's how we trying to prevent this permission structure from interfering with your user experience.

Now if we go back to the sermon distributor component, 00:08:10 and we again open the site views, this time I change it that is doesn't have access. I save it that way. Go to the compiler, compile sermon distributor and install. Let's go back to the code. You'll see that it doesn't have any of that checks in the preachers file 00:08:57 only in the category file. It still redirects to preachers, which in effect means that this one will no longer give any errors, but it will show these ('COM_SERMONDISTRIBUTOR_NOT_AUTHORISED_TO_VIEW_CATECORIES'),'errors'); errors, which relates to the fact that they cannot see the categories. I think some of the advancements that we might still think on doing, is maybe add a field to the component, where the user can change these errors 00:09:31 to show maybe a message of how to purchase access or something. You do realize that at this stage JCB does have the the option to customize any section of code by using what is known as the custom code implementation. I'm not going to demonstrate that, please go look and review those videos. They are on YouTube where you can literally change this whole code block here, and then use your own implementation upon these measures. 00:10:10 Well that is a a quick demonstration or explanation on how to manage the different permission structures for JCB regarding the site front-end. If you do not want that control, you can simply just put it off. I realize that most of you might want to add some custom scripting that adds permissions to the database for that component. That's little bit beyond the scope of where JCB is at the moment. Although that is a nice to have, there are more pressing things that we'll focus on.

Clone this wiki locally