Module: Page Edit Field Permission

[kongondo]

@Mary...With the current module you can't...but...with the following simple change, you can . Of course, you can always just request Ryan to make this configurable (i.e. whether to completely hide the field or just lock it down, etc)...Meanwhile....

1. Create a custom copy of the module

2. Rename the module file from PageEditFieldPermission.module to say PageEditFieldPermissionCustom.module

3. Rename the module class similar to #2 plus change all instances of PageEditFieldPermission (whole word) in the module code to PageEditFieldPermissionCustom

4. Change line #91 in your PageEditFieldPermissionCustom as shown below (see inputfield collapsed setting constants here)

//if($field) $field->parent->remove($field);//comment this out
if($field) $field->collapsed = Inputfield::collapsedNoLocked;//add this line

Haven't thoroughly tested...

[einsteinsboi]

Thank you kongondo... I'll give this a try and let you know. You're awesome

@Mary...With the current module you can't...but...with the following simple change, you can . Of course, you can always just request Ryan to make this configurable (i.e. whether to completely hide the field or just lock it down, etc)...Meanwhile....

1. Create a custom copy of the module

2. Rename the module file from PageEditFieldPermission.module to say PageEditFieldPermissionCustom.module

3. Rename the module class similar to #2 plus change all instances of PageEditFieldPermission (whole word) in the module code to PageEditFieldPermissionCustom

4. Change line #91 in your PageEditFieldPermissionCustom as shown below (see inputfield collapsed setting constants here)

//if($field) $field->parent->remove($field);//comment this out
if($field) $field->collapsed = Inputfield::collapsedNoLocked;//add this line

Haven't thoroughly tested...

[einsteinsboi]

Really strange, my site was working just fine and I editing was some pages, just content, and I also added a couple of new members the usual way, no problems.  Then I decided to try to make the changes to the module.  I created a copy of the module folder and renamed it as you recommended, and renamed the .module file and did a find replace then edited the code in the custom module as you recommended. When I tried to go to the /modules/ page to find and install the new module, it wouldn't see it, and a few seconds later the whole site started throwing an Internal Server Error (500).  I have checked the processwire error log and it shows no errors, and have also checked my cpanel error log, also no error. I deleted the custom module folder but still getting a 500 error.  What could be causing this and how do I fix it?  All other sites on the account are working fine but this one's throwing an internal server error and I can't help but wonder. 

@Mary...With the current module you can't...but...with the following simple change, you can . Of course, you can always just request Ryan to make this configurable (i.e. whether to completely hide the field or just lock it down, etc)...Meanwhile....

1. Create a custom copy of the module

2. Rename the module file from PageEditFieldPermission.module to say PageEditFieldPermissionCustom.module

3. Rename the module class similar to #2 plus change all instances of PageEditFieldPermission (whole word) in the module code to PageEditFieldPermissionCustom

4. Change line #91 in your PageEditFieldPermissionCustom as shown below (see inputfield collapsed setting constants here)

//if($field) $field->parent->remove($field);//comment this out
if($field) $field->collapsed = Inputfield::collapsedNoLocked;//add this line

Haven't thoroughly tested...

[horst]

@Mary: do you have uninstalled the core module before you installed the CostumModule?

There may be chance that are settings in the modules cache that need to be refreshed after you have deleted it manually. Does the Frontend work? If so, you can simply add a line of code to force a refresh of the modules cache:

wire()->modules->resetCache();

If you also cannot use the frontend, you may simply empty the DB table named "caches". (Do not delete the table, but delete all of its records). If this doesn't change the 500 Error, do it again and also check in the table named "modules" around the last entries, (when sorted upon field created), if there exists an entry for your manually deleted CostumModule. If yes, drop that record. Now try to go to the admin again. HTH & good luck.

BUT, BEFORE you start with manipulating the DB, please make a backup!

[einsteinsboi]

Thank you Horst. I had not even had a chance to install the module as I couldn't find it in the list of modules, and then the module admin page stopped loading, and then the site went kaput!

After chatting with my hosting company for a bit they discovered there was a segmentation error and once they changed the PHP version the 500 internal server error went away (https://processwire.com/talk/topic/8268-strange-internal-server-error/) and the site loaded fine.  I still don't completely understand how or why it happened so suddenly.  I'm taking a small break now and will be back to experiment with the custom module tomorrow.  Fingers crossed nothing goes wrong now, will take full backups before doing anything.

@Mary: do you have uninstalled the core module before you installed the CostumModule?

There may be chance that are settings in the modules cache that need to be refreshed after you have deleted it manually. Does the Frontend work? If so, you can simply add a line of code to force a refresh of the modules cache:

wire()->modules->resetCache();

If you also cannot use the frontend, you may simply empty the DB table named "caches". (Do not delete the table, but delete all of its records). If this doesn't change the 500 Error, do it again and also check in the table named "modules" around the last entries, (when sorted upon field created), if there exists an entry for your manually deleted CostumModule. If yes, drop that record. Now try to go to the admin again. HTH & good luck.

BUT, BEFORE you start with manipulating the DB, please make a backup!

[kongondo]

@ Mary,

Some freaky coincidence with the segmentation error?

Just to clarify, there's only two instances inside PageEditFieldPermissionCustom.module where you need to rename 'PageEditFieldPermission'. These are on lines

Line 24: The module class name - class PageEditFieldPermission extends WireData implements

Line 115: wire('config')->paths->PageEditFieldPermission

PageEditFieldPermissionConfig does not need renaming.

Please test on a development server first

[einsteinsboi]

@kongondo, very freaky coincidence indeed! 

Thanks for the tips. What I had done was make a copy of the module folder. I renamed that copy PageEditFieldPermissionCustom and then renamed the .module file and did a find - replace inside the .module file. 

Will follow your exact steps above tomorrow and see how I go. 

thanks again

[kongondo]

If you did a search and replace, you probably also renamed the reference to PageEditFieldPermissionConfig.php in the module file? i.e. line #115 where the file is required_once and line #116 where a function from that .php file is returned. However, if you didn't rename the .php file itself, PHP should just have thrown an error that a file was not found. Hmm..wondering if this is what caused the problem....

require_once(wire('config')->paths->PageEditFieldPermission . 'PageEditFieldPermissionConfig.php');
return PageEditFieldPermissionConfig($data);

[einsteinsboi]

@kongondo

Should have mentioned I did also rename the config file and ran a search replace in that file as well.  I thought you only wanted me to clarify about the .module file.

I think it was definitely a freak coincidence as I never even got to install the custom module. 

[Juergen]

Be careful: break site if using with 2.5.25 in my case.

Take a look at https://processwire.com/talk/topic/9565-upgrade-from-2524-to-2525-broke-the-site/#entry92025

[Soma]

The module states that it's not for 2.5. Last update 2012. Thanks for reporting. Maybe file an issue on github asking for update?

[cstevensjr]

I just opened an issue on this module.  It is very useful in a variety of circumstances. 

[ryan]

I just pushed an update to the module that corrects the issue. This module used a naming format for a file that's not compatible with PW 2.5.11+ (though sounds like it still may have worked up until the latest, but really shouldn't have). If you grab the latest it should work now. 

[Christophe]

Hello,

For an association website, for a member(s) role I have restricted its users: they can only edit the months pages of the Members section of the page tree.

But they could see the other pages (sections). So I've used the Admin Restrict Branch module, so they only see the Members section in the page tree.

In the months pages I'm using a repeater to add several "events" to each month.

But now, the website "contact" wants only the last two fields in the repeater to be editable by the users with the member(s) role.

Is the only way/solution still to use PageTable instead of Repeaters?

It's the first time I'm using Repeaters, and I haven't used PageTable yet.

[cstevensjr]

NB: how can I add 2 screenshots to the post please. I can't manage to do it.

I believe you need to click the "More Reply Options" button, which will bring up the full editor.  Then you can add your images.

[adrian]

@Christophe,

I am not sure about this module with repeaters, but the built-in field-level access control seems to work great with repeaters. If you have PW 2.6.2+ there is an "Access" tab for each field (in the field's settings) that controls which user roles can see and edit it.

Does that take care of your needs?

[Christophe]

Hello Adrian,

I've done it with Templates recently, I should have been curious enough/(rested and) taken the time to check (again?) if it was also possible with Fields.

Thank you for your post.

Now only osteopaths' fields can be edited by them.

And I've hidden the Settings tab from them thanks to Restrict Tab View.

The only (relatively important) thing left now is that they can remove existing (repeater) items, or add some new ones (it doesn't bother if the 3 non-editable fields are required...).

I've tried doing something at the repeater(s) level but I've only been able to make it completely hidden (just seeing a list of ids apparently).

Edit: perhaps Admin Custom Files is the solution...

[Christophe]

What would be the simplest way(s) to add the following css rule in order to hide the trash icon and the add an item link (repeater) (for a page with a specific template and) only when a specific role is logged-in?:

.fa.fa-trash.InputfieldRepeaterTrash, .InputfieldRepeaterAddLink {display: none !important;}

Lastly, I've, for example, created a templates-admin folder and a styles sub-folder, and have done some tests, but it hasn't worked yet.

Could I put a condition more or less like this one? (and where/how?):

<?php if($this->user->hasRole("membres")) {
        echo "<link rel='stylesheet' href='/site/templates-admin/styles/membres.css' />";
    } ?>

Thanks in advance.

It's an issue because the users with the role can only edit 2 fields inside the repeater item, but can add or remove a repeater item without any problem.

[bernhard]

hi christophe,

maybe this helps: put this in your /site/ready.php

$wire->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event){
    $process = $event->object;
    $page = $process->getPage();
    $user = wire('user');

    // example: limit code to one template
    if($page->template != 'basic-page') return;

    // example: limit it to user role
    if(!$user->hasRole("membres")) return;

    $config = wire('config');
    $config->scripts->append($config->urls->templates . 'scripts/yourscript.js');
    $config->styles->append($config->urls->templates . 'styles/yourstyle.css');
});

of course you will have to put your script or style-files in the appropriate folders (in the example above it would be the folder /site/templates/scripts or /site/templates/styles

[Christophe]

Hi Bernhard,

So, I've copied the code in ready.php (or _ready.php):

<?php

$wire->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event){
    $process = $event->object;
    $page = $process->getPage();
    $user = wire('user');

    // limit code to one template and to user role
    if($page->template != 'planning-child' && !$user->hasRole("membres")) return;

    $config = wire('config');
    $config->styles->append($config->urls->templates . 'styles/membres.css');
});

It doesn't seem to work as it is.

I've also tested it with only

if(!$user->hasRole("membres")) return;

I've tested it in case with

$config->styles->append($config->urls->templates-admin . 'styles/membres.css');

as some Back-end/Admin styles are there. Edit: I've just tried with ready.php in /site/templates-admin ***

(The insertion of "-" caused problems when I tested the path to /site/templates-admin/styles/membres.css some days ago, so I tried to add some curly braces, etc. at that moment.)

I can't see membres.css loaded with the developer tool(s).

*** Edit 2: I've just realized after writing the "Edit" that ready.php has to be in /site

I think I've put it in /site/templates because I have an _init.php file there...

[Christophe]

It works with only

if(!$user->hasRole("membres")) return;

if($page->template != 'planning-child' && !$user->hasRole("membres")) return;

doesn't seem to work.  (Perhaps there's a "conflict"...(?))

// limit code to one template
if($page->template != 'planning-child') return;

// limit it to user role
if(!$user->hasRole("membres")) return;

as you had put it seems to work. But does this block of code(s) (if used together) mean that both conditions have to be "ok" (or one or the other)?

Edit: (or the first one that is "ok"...)

For my project

if(!$user->hasRole("membres")) return;

is enough, but I'm wondering...

Thank you so much! (It's one of the only things that last(ed) in order to finish the website.)

NB: I'm leaving my "mistakes" in case it helps other people

[bernhard]

You would have to use OR instead of AND

Glad it helped

[Christophe]

I can't use OR (or ||) in this case, as the template is for a type of page edited by other roles with more permissions.

In this project, as it is, I can't currently see if/how (using)

// limit code to one template
if($page->template != 'planning-child') return;

// limit it to user role
if(!$user->hasRole("membres")) return;

,

// limit it to user role
if(!$user->hasRole("membres")) return;

// limit code to one template
if($page->template != 'planning-child') return;

or only

// limit it to user role
if(!$user->hasRole("membres")) return;

would be different (or not).

I'll test it in the future if I have the opportunity.

[Christophe]

Another problem I've just discovered :/, now when I log-in as the "manager" user (not the superuser), I don't have access anymore to the page(s) tree and to the users ("membres" role) that I could add or edit.

I've deactivated ready.php (ready_deactivated.php).

I've disconnected and cleaned the browser's cache.

Now when I click on the Users link I have the following message (translated):

ProcessWire: You don't have permission to execute this module - ProcessPageLister

What happened?

I don't remember it not working before using ready.php (but I can't say I'm 100% sure).

I haven't changed anything to this role recently.

Edit: it's apparently due to Admin Restrict Branch. I have to find why, as it worked well before and I only restricted a Specified Branch Parent for the "Membres" role.

[adrian]

Edit: it's apparently due to Admin Restrict Branch. I have to find why, as it worked well before and I only restricted a Specified Branch Parent for the "Membres" role.

 

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered with AdminRestrictBranch has been fixed.