I really dont see the need for this to be in the core.

@brianteeman why? There's a very good reason: allow to view the page, but NOT to change anything on it. I already described it and even mentioned at least one situation, when this can be useful - on demo sites.

It should be noted that just hiding the apply and save buttons doesn't prevent the user from saving. It just needs a bit more work then.

I also like Brian don't see the need for this in core. A demo site isn't really the purpose of the CMS. That's really a rare exception. And honestly, if you want to sh them the settings, just screenshot them and make them available. It's crazy to show a form which isn't allowed to be sent.

That's such a special case, I don't see that we should go this way, closing.

Are you all serious? I'm really surprised, that you all "don't see", when this is clearly THE case.

No, demos are not a rare exception and no, screenshots are not enough at all. Also demo was just an example and there might be other uses. Even OpenCart with its super stupid and basically non-existing permissions system has "access" and "modify" actions, where the first one allows you to access (view) extension's settings only. Due to this I can safely setup a demo On OpenCart and have to constantly change the code for Joomla. Otherwise everybody will be able to setup any module or plugin the way the want. But DO NOT want them to do that, only open and view the settings page, which is soooooo normal.

So yes, it should be added in the core and it's actually a 1 minute job. If you "don't see", then don't use it - others will. Why did you decide for everyone, that nobody would want it? I'm honestly very, very surprised, that such an obvious lack of functionality is not obvious to you.

If you can give me an usecase example that doesn't include a "demo" modus, then we may be able to reevaluate. I don't see how it should be normal for users to see any form (settings or whatever) when they are not allowed to save/send the form.
That's why we have regular item views which btw already have a view permission (view level) assigned. But I don't see why such a view should be available for the component settings.

it should be added in the core and it's actually a 1 minute job.

No it's not. Because your code suggestion would be a security issue. Just hiding the buttons doesn't prevent from saving. You need some checks in other places as well. But if that works for you, just do a template override for the layout and you're done.

If you can give me an usecase example that doesn't include a "demo" modus, then we may be able to reevaluate. I don't see how it should be normal for users to see any form (settings or whatever) when they are not allowed to save/send the form.

For example, I can have an extension, which contains some important data in settings. Imagine, I have some kind of a manager, whom I need to allow to see these settings, in case he forgets something, but not edit them. This can be basically anything: email, account number, my own personal information, which I display on frontend, and so on. Only I can change this information, but not anybody else.

This is a very simple example, which a lot of site owners may utilize. I personally don't have a manager and need this to create a decent demo site for my extensions, because I want people to actually "touch" my stuff. Providing an access to actual extension backend is always better than posting screenshots.

So now we have at least two examples, but I can come up with more, if you want me to. But I think, example with manager is pretty explanatory. You, of course, can say something like "why don't you write this important information down and give it to a manager", but that's not an option at all. I want information to be at hand all the time. I can edit this information any time. I don't want to provide this information to my manager every time I edit it. The less actions are made, the safer it is.

I saw different frameworks, I code in multiple of'em and most has View permission. This is absolutely normal, when you let to view, but not to use. All my components have the View restriction and to implement this I had to completely replace "core" permissions, because they're not flexible enough. If I could assign my own permissions to every module and plugin, I would never bother you. But I can't because module and plugin permissions are handled by Modules and Plugins components.

Example with manager: Create a "Custom" module and put the important information into it, publish it on cPanel and access restrict it to the manager group. Way better than letting anyone see the settings page.

I saw different frameworks, I code in multiple of'em and most has View permission.

Joomla of course has view permissions. They're called view levels (eg "public", "registered") and can usually be set for categories and items. But the settings rightfully don't have view levels because (I still think) it makes no sense to show the form without letting people change it.

Joomla of course has view permissions. They're called view levels (eg "public", "registered") and can usually be set for categories and items.

These are for frontend, not for backend. It's a bit different. I was talking about backend content management.

But the settings rightfully don't have view levels because (I still think) it makes no sense to show the form without letting people change it.

I am a senior developer myself and, trust me, I don't see a point in many, many customer requests. Some of them are completely ridiculous, but even these ridiculous requests are often requested by multiple customers. This means, that there's a need for such requests, no matter what I think.

I already gave you two examples of when View permission is necessary. I don't require you to understand it, because obviously you personally don't see any use for such feature. But I do. And I'm pretty sure other people also will. In my opinion, easy setup of demo Joomla installation, when you are able to display your extensions without worrying, that somebody will change and break something, is a pretty good reason alone.

But I also gave you another example. If you don't like the settings concept, imagine a list of items. Very often not every possible information about list items is displayed - you need to open the item to see all info. Take article as an example: manager needs to see all article info, but not change anything. Replace article with ad, event, comment and gazillion other types of content and you'll get the idea. In this case I'm talking about components, which also lack View permission. So you can't achieve the task I describe, if you don't create your own backend interface. Can't be implemented using generic config.xml and standard Joomla functionality.

I really hope this time you'll understand, that View permission IS necessary and that it can be used in multiple situations.

As a senior developer then I am sure you are able to submit a pull request for this. Maybe if we can see it in use them we will be convinced.

These are for frontend, not for backend. It's a bit different. I was talking about backend content management.

The viewlevels are used both in front- and backend.

Some of them are completely ridiculous, but even these ridiculous requests are often requested by multiple customers. This means, that there's a need for such requests, no matter what I think.

No, it doesn't need that. It maybe needs education, but ridiculous requests should not be fullfilled.

and so far we only have one request ;)

The viewlevels are used both in front- and backend.

Enlighten me then, how can I use that viewlevels to allow viewing, but disallow saving for component items and module/plugin settings.

No, it doesn't need that. It maybe needs education, but ridiculous requests should not be fullfilled.

You didn't get the point. What's ridiculous for you, is pretty fair for others.

As a senior developer then I am sure you are able to submit a pull request for this. Maybe if we can see it in use them we will be convinced.

Don't get me wrong, but I feel myself extremely uncomfortable on GitHub. It's too geeky for me with all that markdown language instead of WYSIWYG and extremely confusing PR system. Tried to learn, how to create pull requests a couple times, but failed and stopped trying.

But it's all pretty simple actually. There's a core.edit permission, which allows you to open AND edit item from the list:

if ($canDo->get('core.edit'))
{
	JToolbarHelper::editList('plugin.edit');
}

Same core.edit permission enables save/apply buttons on item view (which is OK):

if ($canDo->get('core.edit'))
{
	JToolbarHelper::apply('plugin.apply');
	JToolbarHelper::save('plugin.save');
}

Probably the only thing you have to do here is change the permission on items list to core.view and add this permission to core permissions list. This way user will be able to open the item, but not edit, because save/apply functionality will be turned off for him. That's basically it.

Sorry but as I said before - if this is so important to you and we are all fools for not understanding then please submit a pull request. I am not a senior developer, I am not even a junior developer so I am sure you can work out how

Sorry, but like I said before, I don't want to spend any more time on overcomplicated PR system. Plus I already explained myself very, very clear. Here's some kind of PR for you here:

if ($canDo->get('**core.view**'))
{
	JToolbarHelper::editList('plugin.edit');
}

This is more than enough, if you actually DO want to get the idea and implement it, not just mock on me and constantly tell, how you all "don't see"

its you that wants the PR - not us - but you seem to think you can expect others to do the work for you. I'm out

You probably didn't even read my replies, if you're saying, that I "wants the PR". I never did. I only suggested to add a core.view permission and explained in detail, why it is necessary. But you, unfortunately, so much obsessed with your "vision", that even don't want to listen and discuss anything.

I told you pretty clear, that I don't know, how to create PRs and that GitHub is too geeky for me in general. I'm not a lazy guy, it's just not my site, that's all. I don't use it often, because I prefer more clean UI and less confusing functionality. This is you, who applied your own vision again and decided, that I want others to work for me. If you do this every time you find someone, who disagrees with you, well... you probably don't have much friends. Try to be less judgemental next time and maybe something really good will come out of your conversation with the others.

To conclude all this, if you don't want to implement it, only because you "don't see", fine. So be it. Have fun being out or whatever you're doing.

@thekrotek
it is not 1 minute job, tha you implied

if ($canDo->get('**core.view**'))
{
	JToolbarHelper::editList('plugin.edit');
}

• the above is not enough, the above will only add the button, you need to update form loading code too, and this may include several views and then several controllers code and in the latter, probably adding a new method like "allowFormView"

• and it is not only about core code, 3rd party components will need to make use of it too, but i guess if your extension is e.g. only a plugin and/or module then yes , adding to the core (plugin manager / module manager) would be enough

• also even if a extension implements this, it may trigger some plugin during form loading that will do "core.edit" check thus ... a no-access exception will be thrown, because the plugin has not been updated to support the new feature

and then you will get some bug reports here,
almost no new feature is 100% bug-free and-or problem-free on first implementation

Finally if your extension is a component then you can implement this without any changes to the Joomla core code

Finally if your extension is a component then you can implement this without any changes to the Joomla core code

You definitely didn't read the above discussion. Right in my very first message I said, that I already implemented it in all my components, but I can't do it for modules and plugins. Please, read the whole discussion, not just last message of it.

@thekrotek
ok maybe i have not read all your messages properly

but i dont think that you read my single message,
because you focus on the non important point if you have an implementation for it, in your components, and forget of everything else that i have said

i was confused
-- that you have implemented this for your components,
-- but then you suggested that adding this to the core is a simple as showing the "Edit" button, plus you miss the implications of plugin triggering of plugins,

these 2 things are contracting

anyway i was trying to contribute to the discussion because i thought your suggestion maybe somewhat useful to extension developers

if you want to see this having chances of being added, then spend some time to get knowledge of GIT (or just try to use the Github UI), and then make a PR, nobody here was born with knowledge of GIT / github, and your efforts to learn git will be useful for your extensions too

@ggppdk I don't think you read my messages at all and this is why both your replies are absolutely irrelevant. I don't have nor time, neither desire to explain you everything from the start personally. I already did all the explanation above and made myself very, very clear. If you wish to continue this discussion, please, READ this discussion FROM THE START, not just my last message, on which both your replies are based. If you don't want to bother yourself with reading, then don't bother with replying either. Currently our discussion is completely pointless and irrelevant to the one above.

This is going to nowhere and just a waste of time