Interest in admin read-only permission?

[bernhard]

Hi everybody,

I've asked Ryan about his opinion of a new permission that makes it possible to view pages in the backend but not edit them. This was the description of the idea/request:

Spoiler

Quote

I'm using PW a lot for backend stuff and there is one thing that is really missing in my opinion: A permission (or a way) that makes it possible to VIEW a page in the backend but without it being EDITABLE by the user.

 

PW is so great to put together templates with several fields. You have a usable database setup in no time. All with proper user login and access control etc.; But this flexibility is at the moment limited to the page edit permission!

Imagine you want to manage a list of cars or pets in the PW backend and show this list to logged in users (also in the backend). It would be really easy to create this list (Lister, AdminDataTable, RockGrid...), but it would NOT be easy to show the details of each entry to the user without him having edit rights. You would either have to create a frontend template and send your user there (but then you need to create a whole frontend setup and I have several installations of PW where I use the backend exclusively), or you would have to create a custom process module just for this simple task.

 

It would be great if there was something like the page edit screen just without the editable fields. Maybe all fields could be locked for such users to make them read-only. Maybe we don't need a new permission and could just add a new admin process like ProcessPageAdminView that lists all fields and their content but in a read-only state? The users could then view the page in the admin when opening $page->adminUrl (similar to $page->editUrl), but they would not be able to do any modifications to the page.

 

I've done that VERY hacky in my setup by hooking the page saving process and throwing an exception when the user wants to save a page he should not save. But that is really not the way someone should (have to) do it.

 

This new feature could be used in a huge variety of ways - we could for example quickly build docs for our clients directly in the backend:

Create a template with title + body field.

Create a page with that template somewhere in the pagetree.
eg Hello World, This is content of hello world.

Create NO php file for that template.

The page would NOT be viewable in the frontend.

The page could be viewable in the backend (read-only) for other users and editable for superusers (and all others having edit permission).

Maybe this admin-view of the page could even open up when the user clicks the "view" button in the pagetree?! (If frontend viewable then show $page->url, if backend viewable then show $page->adminUrl)

The PW template/page system is so awesome! I think it would be great to bring this concept to the backend as well to not only make it possible to create all kinds of EDITABLE pages in no time but also make it possible to create all kinds of (admin)VIEWABLE pages in the backend in no time.

 

There are so many scenarios where this could be useful... show details of bookings, details of transactions, details of user data, details of logged emails etc etc etc...

 

In short: The idea sounds interesting to him, but he is not sure if that belongs into the core as that was the first request in that direction in the last 10 years. He also mentioned "demo" mode setting as a possible solution. I've thought of that as well, but it is not possible because it deactivates all POST data and so you completely break all features that rely on POST. It's also not a great solution because it still loads all the inputfields (as editable inputfields) and not in locked mode. For example a ckeditor textarea would still load the whole editor with all it's plugins and with the scrollbar and maybe hanna code tags while it should actually load pure read-only HTML with text formatters applied.

I'd love to hear your opinions about such a new permission. Have you ever wished it would exist? Is it something you have never needed in the past 10 years? Is it something you have just never thought of? I know that @Macrura is also doing a lot in the backend, so I'm especially interested in your opinion and experience with that topic. Also @BitPoet and @Robin S

Finally I think that this SHOULD be part of the core. I think this situations should be a no-brainer, and of course should be maximum secure. I don't think we should mess here with hooks to adopt the system to such fundamental needs. Also we should not have to develop a module for just showing some read-only page data to our users (like a quick wiki for example). I'll collect some feedback here in this thread and then try to communicate a condensed feedback to Ryan.

PS: I can remember that there has been some discussion about that already in the forum, but unfortunately I could not find the topic. Maybe someone has a link for me?

[LostKobrakai]

1 hour ago, bernhard said:

Finally I think that this SHOULD be part of the core. I think this situations should be a no-brainer, and of course should be maximum secure. I don't think we should mess here with hooks to adopt the system to such fundamental needs. Also we should not have to develop a module for just showing some read-only page data to our users (like a quick wiki for example). I'll collect some feedback here in this thread and then try to communicate a condensed feedback to Ryan.

Can you please share why this should be part of the core in your opinion? To which problem(s) processwire users have would this be the solution?

[Autofahrn]

20 minutes ago, bernhard said:

I can remember that there has been some discussion about that already in the forum, but unfortunately I could not find the topic. Maybe someone has a link for me?

Not sure if you refer to my experimental tweak to get a read-only demo view for the RepeaterFlex in admin: https://pwflex.team-tofahrn.de/?preview=PG132107923

There only was a miniature "discussion" in closed RepeaterMatrix section:

 

[Macrura]

@bernhard, perhaps you could hook into the URLs for the edit buttons and rewrite those to a custom view process which displays the uneditable content of the page?

like

admin/page/view/?id=1234

and then in your view process you could even render custom views, based on files in the templates folder... possibly make a render function that is similar to the core buildForm, but instead outputs only the markup value for each field..

 

[arjen]

Quote

Maybe we don't need a new permission and could just add a new admin process like ProcessPageAdminView that lists all fields and their content but in a read-only state?

We've done this before by using a hook to switch a field to readonly based on the role. It is not that hard to set-up imho. In that particular set-up we had like 20 roles and a lot of permissions so adding another role/permission did not feel right especially since the roles reflected the clients organization structure. Or even replace the fieldgroup with your own markup.

[wbmnfktr]

I almost understand your need (or desire) for this kind of feature.

I have had several situations in which I wanted to show clients or others the backend without the ability to change/save anything while still being able to present the full/all capabilities of ProcessWire (and therefore CKEditor textareas, autocomplete in page references, and so on...).

I created dummy instances of ProcessWire to show it and imported database backups a few days after to get everything back to normal.

While your idea is interesting in some kind... it wouldn't fit my need to show people all kinds of things ProcessWire can do. They wouldn't see the CKEditor in all of its glory - for example. Maybe I got this wrong but... half rendered pages wouldn't work for most of my suspicious clients in regards of ProcessWire. They want to see the "WORD-like textarea" and want play around with it. 

Nonetheless I can imagine situations in which this would be handy and a great addition but I really don't know how much work this kind of user permission would cause - either in core or as a module... so... sorry for not answering your question. ? 

Admin read-only permission: could be nice
Demo mode for new clients: oh yes... please
A mix of both: well... why not

[bernhard]

5 hours ago, LostKobrakai said:

Can you please share why this should be part of the core in your opinion? To which problem(s) processwire users have would this be the solution?

Well, I tried to explain the problems.. and I was asking if I'm the only one having those problems, which I can't believe.

3 hours ago, Macrura said:

bernhard, perhaps you could hook into the URLs for the edit buttons and rewrite those to a custom view process which displays the uneditable content of the page?

Thx. Maybe this could be done. But imho pw is a framework and showing content read only to some users without having to build a custom frontend should be fundamentally built into the system.

3 hours ago, arjen said:

We've done this before by using a hook to switch a field to readonly based on the role. It is not that hard to set-up imho. In that particular set-up we had like 20 roles and a lot of permissions so adding another role/permission did not feel right especially since the roles reflected the clients organization structure. Or even replace the fieldgroup with your own markup

That sounds like an admin view permission would make sense. The problem with this approach (which I also took for my crm) is that it is inconsistent with how the pw permissions work.

Usually you add a permission to unlock features. Without an admin view permission I'm locking down fields in the edit screen, but the page still has the editable state internally. That is simply not good.

And that's why the core imho should support an additional permission that is less mighty than the edit permission.

Such a permission could also make public pages in the backend possible. Which might be a good idea or not.. 

[teppo]

9 hours ago, bernhard said:

I'd love to hear your opinions about such a new permission. Have you ever wished it would exist? Is it something you have never needed in the past 10 years? Is it something you have just never thought of?

Finally I think that this SHOULD be part of the core. I think this situations should be a no-brainer, and of course should be maximum secure. I don't think we should mess here with hooks to adopt the system to such fundamental needs. Also we should not have to develop a module for just showing some read-only page data to our users (like a quick wiki for example).

If I'm being completely honest, I've never really had this need, and I don't think that I'd have much use for this feature. Then again It's clear that you've built much bigger – and much more complex – admin side features than I've ever even thought of, so it's no surprise that your needs are also somewhat different from mine. For me the admin is mostly for managing content, and when that content needs to be viewed by non-content-editors, I generally prefer to create my own views for it ?

While I do understand your reasoning here, at the same time I think that what should be in the core are features that are commonly needed. Like Ryan, I'm not really sure that this as a very common need, and as such I think that it might be better to solve it with a module (at least for the time being). Personally I'd be slightly worried about the security of this feature if it was in the core: sure, Ryan has been great at covering all the bases when it comes to security, but making notable tweaks to the permission system is still a potential risk.

I get that it's even more of a risk when you add it yourself, but when it's a third party module there's zero chance of it affecting anyone who doesn't specifically install it.

Quote

I've done that VERY hacky in my setup by hooking the page saving process and throwing an exception when the user wants to save a page he should not save. But that is really not the way someone should (have to) do it.

I was actually going to suggest this – but then I re-read your post, and realised that you had already ruled it out ?

In my opinion this doesn't  don't seem like a very hacky thing. Hooking before page and fields can be saved and preventing seems like a proper solution to me. If you do that and also hide the "save" buttons (and prevent submitting ProcessPageEdit form in other ways), you'll be really close to what you're suggesting here.

[arjen]

On 6/3/2019 at 7:52 PM, bernhard said:

 That sounds like an admin view permission would make sense. The problem with this approach (which I also took for my crm) is that it is inconsistent with how the pw permissions work.

I've had to correct myself we didn't even hook, but use the "What roles can view and/or edit this field?" checkboxes and the Access Toggle "Show field in page editor if viewable but not editable (user can see but not change)". We've created a process module which listed all the fields and the corresponding settings to keep an overview on all the settings of the fields. Also we made it easy to bulk edit these field settings/permissions. That being said I doubt if I understand your question right since we already have view/not-edit. We only used hooks to change the output of the fields. Apologies, these kind of requirements can be hard to understand. I think I'm understanding your need since to want view not edit permission on a page level? 

So to summarise: we didn't need that kind of permission, but rather a per field permissions which is already available.

[bernhard]

Thx arjen!

Never used field permissions because I've never needed them. Or actually I've just hooked the field and set it to locked collapsed state.

I think your scenario is close to mine. The solution sounds great from a technical point of view and for the tools and settings we have. But I think it is not the way it should work!

Imagine a site that manages users and invoices. That's all content, isn't it? So a content management system should be perfect tool for this job. Imagine you want to store forename, surname, email for users and you want to store net value, gross value, items and date for invoices.

Processwire would be great for that, wouldn't it?

Now imagine you want to show all invoices to some users, but the users should not be able to edit them. Not so easy! We have the tools for listing basic info (date, net, gross), but how could we show all details of the invoice to the user? The edit screen would be perfect. Well, if the fields were not editable there...

Setting the fields themselves to read only sounds like a proper solution, but that's a lot of effort for such a simple and basic task! Imagine you had more fields! And imagine you added a new field later to the invoice template and forgot to set the field restriction... You'd have an editable field on a read only page.

IMHO The fact that you've built your own custom process module for this proves that the tools we have are not enough!

I just want to have a role that can see all data of invoice templates but not edit them. I think this is a fundamental hickup in the permissions we have.

Or it is a missing process in the backend. Maybe we need a process that can VIEW pages in the backend if the user has view permission, even if the corresponding template file for frontend display does not exist?

Not sure what the best solution would be, but it's not the ones I've used and heard so far ?

I'm also happy to hear if someone disagrees. Have a great week and thanks for your opinions!

[arjen]

16 hours ago, bernhard said:

Processwire would be great for that, wouldn't it?

I don't think I would build such a system in ProcessWire. Money stuff I would prefer to be handled by a system which has some kind of Event Sourcing. But I get your idea ?

16 hours ago, bernhard said:

Setting the fields themselves to read only sounds like a proper solution, but that's a lot of effort for such a simple and basic task! Imagine you had more fields! And imagine you added a new field later to the invoice template and forgot to set the field restriction... You'd have an editable field on a read only page.

 IMHO The fact that you've built your own custom process module for this proves that the tools we have are not enough!

True. When you have 300+ fields it will become a tedious job to add another role and assign all fields. And than another role. 

16 hours ago, bernhard said:

 I just want to have a role that can see all data of invoice templates but not edit them. I think this is a fundamental hickup in the permissions we have.

We only needed certain fields were editable and some not. I can see your point.

That being said maybe a better solution would be to create a Process module which can handle these bulk actions. Currently I'm not working on that project anymore, but I've developed the basic batch functionality in a few days work. I would love to do a UI/UX/mock-up on how this could work. 
 

[LostKobrakai]

I'm not really sure why we would actually need a new permission here at all. We already have a permission to view a page and one to edit a page. It's just that ProcessWire is build with custom frontends in mind and "viewing" a page is generally considered to be done by viewing the page on the frontend. That's why we have ProcessPageEdit and not ProcessPage. I can see that repurposing ProcessPageEdit one could make it basically behave as though any field would be set to "not editable" when a user only has permission to view a page, but not edit it. I just expect that the implicit notion of "you look at a page on the frontend" is build into many places. Like everywhere you currently have a link to edit a page the permission checks need to be changed, it probably cannot be named "edit" anymore or at least must dynamically be switched between "edit" and "show". The latter might still cause some confusion.