None-Superuser who can create templates

[AJOSPACE]

Hi Everyone,

First of all, a big thank you to the Processwire team. Ever since I started using PW I never used anything else, or took any job where I would not be allowed to use it if I deemed it the best tool for that job. It has allowed me to create demo forms and presentation screens live on the spot during negotiations and training sessions, which sometimes can have a great effect. It has also allowed me to reach interesting people with the open source message.

But I do have a question. Is it possible to have a none-superuser (can't manage superusers), but who can create fields and templates?. It seems to me now that only superusers can create fields and templates.

As with most things in Processwire, I have a feeling the solution will be one easy switch somewhere, but I just can't find it.

 

[bernhard]

Hi @AJOSPACE

Why do you want to have a non-superuser that can do that? Please explain your usecase...

[WillyC]

super user.s required to create fielders y templatos 
purposefulness of super user this.is
with out such purpose 
is not.super
 

[szabesz]

On 8/3/2019 at 8:43 AM, AJOSPACE said:

It seems to me now that only superusers can create fields and templates.

As with most things in Processwire, I have a feeling the solution will be one easy switch somewhere, but I just can't find it.

If you try to create some sort of page-builder featureset this way, than this is not what you are looking for as fields and templates are for developers (and most of the time they are the only superusers in the system...). People usually use RepeaterMatrix or sometimes the PageTree to implement page-building functionalities. There are plenty of examples in the forum demonstrating these. Some devs used custom coding too, again, they showcased their work in the forums.

[teppo]

Don't think I've ever used this, but according to the ProcessTemplate core module the template part should be possible if you create a new "template-admin" permission and assign it to any non-superuser role. Based on a quick test it seems to work. ProcessField supports similar "field-admin" permission, which might give you the expected result regarding fields.

This does seem like a rather unlikely need, so I'd first check if this is really what you want. Certain tasks are limited to superusers for a good reason ?

[adrian]

6 minutes ago, teppo said:

Don't think I've ever used this, but according to the ProcessTemplate core module this should be possible if you create a new "template-admin" permission and assign it to any non-superuser role. Based on a quick test it seems to work.

And there is a matching "field-admin" permission as well: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Process/ProcessField/ProcessField.module#L53

[teppo]

7 minutes ago, adrian said:

And there is a matching "field-admin" permission as well: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Process/ProcessField/ProcessField.module#L53

Yeah, edited my message as well. Didn't read the original question properly, thought it was only about templates. Just gave these both a try and so far they seem to work – though this is a rare use case, so wouldn't be entirely surprised if there were some gotchas along the way ?

[AJOSPACE]

Hi Guys, I honestly did not expect so many of you to jump in and try to help so fast. In the future if I need help I will try to explain the use case a bit as @bernhard  suggested.

But just like everything else with Processwire, the solution was way simpler than I even hoped it to be. A big Thank You you @teppo, you did understand me, cause your suggestions were exactly what I needed and solved my problem.

Just in case the use case is still relevant:
The normal roles systems of PW has always worked well for me as it is, and in some sensitive data systems, i have come to rely heavy on PW permissions in systems where I was the only one who needed to add fields and templates and everyone else was only for data viewing, entry and editing. However I have one case now where I want them to be able to build their own PW form in the backend to register incoming data, because then I get to do only the fun part: 1: spinning up VMS, Virtual hosts and clean PW installs and then 2: writing the scripts for  reports and graphs from that data.

Basically with this now in my systems, I can use PW the way I used MS Access back in the days. I train the datacollectors to build their own datacollection tools, and I focus on reporting, without the risk that a malevolent other super user can remove me or uninstall the Versioning Module.