pogidude
Members-
Posts
122 -
Joined
-
Last visited
Everything posted by pogidude
-
Attached is my module file PageEditPerRole.module So, you go to a role and add pages that a user with that role can edit and add pages to. Now, the problem starts when user creates a page. It will look like this: No templates in the dropdown. That's because of this lines of code in the ProcessPageAdd::getAllowedTemplates() method: if($this->parent->is(Page::statusUnpublished)) { $parentEditable = $this->parent->editable(); } else { // temporarily put the parent in an unpublished status so that we can check it from // the proper context: when page-publish permission exists, a page not not editable // if a user doesn't have page-publish permission to it, even though it may still // be editable if it was unpublished. $this->parent->addStatus(Page::statusUnpublished); $parentEditable = $this->parent->editable(); $this->parent->removeStatus(Page::statusUnpublished); } foreach($this->fuel('templates') as $t) { if($t->noParents) continue; if($t->useRoles && !$user->hasPermission('page-create', $t)) continue; if(!$t->useRoles && !$parentEditable) continue; if(!$t->useRoles && !$user->hasPermission('page-create', $this->parent)) continue; I've highlighted the relevant lines. Now here's the weird part. I added the following lines of code just right before the code above somewhere in line #100 foreach($this->user->roles as $r){ if(count($r->role_editable_pages)){ error_log('=== #pages: '.count($r->role_editable_pages). ' template: '.$r->name); foreach($r->role_editable_pages as $e){ error_log('===== page name: '.$e->name); } } } and here's what you get: what is going on here? Here's the ProcessPageAdd.php file I hacked from core ProcessPageAdd.module
-
Is it possible to create a Templates select box field in ProcessPageEdit?
-
when creating and adding a field to a fieldgroup: //add role_add_children_pages $field_addable = new Field(); $field_addable->name = 'role_add_children_pages'; $field_addable->label = 'Pages users with this role may add to'; $field_addable->labelFieldName = 'path'; $field_addable->type = wire('modules')->get('FieldtypePage'); $field_addable->inputfield = 'InputfieldPageListSelectMultiple'; $field_addable->description = 'In order to add to child pages, this role must have page-edit permission or the user must also have another role with page-edit permission.'; $field_addable->save(); $this->message("Added field 'role_addable_pages' to the role template."); $fieldgroup = $this->fieldgroups->get('role'); $fieldgroup->add($field_addable); $fieldgroup->save(); I'm curious what the labelFieldName attribute is for. the one assigned with 'path'
-
Yes. but that doesn't give the user *permission* to use the template. It's just that you have the Page::addable(), Page::editable(), etc.. defined as method hooks in the PagePermissions class, then there is also User::hasPermission() which are also used but these aren't hookable.
-
PageArray field in a role doesn't have anything when adding a page
pogidude replied to pogidude's topic in General Support
found something weird that I'm not sure why it's happening. So, I added the field "role_editable_pages" to the "role" template with type "InputfieldPageListSelectMultiple". then, I assigned four pages to the field => "about", "contact", "news", "staff". Now, I got my hook "hookPageEditable" which when editing a page (or showing edit links) checks if a role that a user is assigned to has the current page in the "role_editable_pages" field. For debugging, I list all the items in the role_editable_pages field... which should list 4 items as stated above. Here's what's interesting. When I'm editing a page like say the "about" page, all 4 items get listed. But, when I'm adding page under the "about" page and in the ProcessPageAdd::getAllowedTemplates() method this line is run: $parentEditable = $this->parent->editable(); //$this->parent in this case is the "about" page when I list the items in the role_editable_pages field, only 3 items get listed and the missing item is the "about" page. This is totally confusing to me since I'm not sure what the relationship between the field in the "role" template is and the about page. -
Just wondering what the idea behind why ProcessPageAdd::___execute() method is hookable? Example of situation where I might want to use it?
-
Other than the hookable methods in PagePermissions class, are there other permission methods I can hook into? I'm looking to *override* what template is available (in the dropdown select) for the user to use when they create a new page.
-
In my module, I have this: /** * Attach our hooks to Page::editable and Page::viewable * */ public function init() { $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); then the callback function: /** * Check if this page, or any ancestor pages, are editable * * From Netcarver * */ public function onMyBranch($page) { $user = $this->user; //get the roles user has $user_roles = $user->roles; //set to false until proven otherwise $page_on_my_branch = false; foreach($user_roles as $role){ $editable_pages = $role->role_editable_pages; if(count($editable_pages)){ $page_on_my_branch = $role->role_editable_pages->has($page); //scan ancestors if applicable if($this->scan_ancestors && !$page_on_my_branch){ $parents = $page->parents; while(!$page_on_my_branch && count($parents)){ $p = $parents->pop(); $page_on_my_branch = $role->role_editable_pages->has($p); } } if($page_on_my_branch){ //page is editable, return! //return $page_on_my_branch; } } } //explicitly return false? return $page_on_my_branch; } /** * Page::editable hook * */ public function hookPageEditable($event) { if($event->return) return; if($this->user->hasPermission('page-edit')) { $event->return = $this->onMyBranch($event->object); } else { $event->return = false; } } Note the role_editable_pages field in the $role variable which is assigned to $editable_pages variable. It's used to store PageArrays. Now, when creating a new page, ProcessPageAdd does it's thing and in ProcessPageAdd::getAllowedTemplates() method, there is this line in line #102: $parentEditable = $this->parent->editable(); so the Page::editable() method is called and my hook runs and calls onMyBranch() method. which runs the foreach() loop. then the conditional check for $editable_pages. But this time, $editable_pages has no Page objects in it. what gives? If I edit a page, my hook still runs and $editable_pages has the Page objects that I've saved. Attached is the complete code. PageEditPerRole.module
-
the ultimate goal is to restrict a user to create pages only on specific branches and what types of pages they can create on that branch.
-
Thanks ryan. Anyway, let's forget about the repeater field for now. My real question is, how do I create a select box or something similar that allows a user to select page templates.. as in my original question
-
Thank you kongondo.. the links you posted will help with the repeater stuff.. Now if I can just create a page template select box.
-
I'm updating this module. and I'm trying to add a field/form like in the screenshot. Where the admin can select a page that users will be able to add to (left side) and what templates they can add (right side). This should work like a repeater field. I can build the first part. I'm not very sure how to build the second part since the second field, in the repeater, is a select field of templates. Oh yeah, I'm not even sure how to programmatically build a repeater field. Here is my code: public function ___install() { .... //add role_add_children_pages $field = new Field(); $field->name = 'role_add_children_pages'; $field->label = 'Pages users with this role may add to'; $field->labelFieldName = 'path'; $field->type = wire('modules')->get('FieldtypeRepeater'); //now what?? //$field->type = $field->description = 'In order to add to child pages, this role must have page-edit permission or the user must also have another role with page-edit permission.'; } or if there's a module that uses repeater fields in a similar way I can take a look at that.
-
Just discovered another one - which I've been wondering didn't exists. It's "page-add" now.. are you sure there aren't any more of this *secret* permissions? scratch that. false alarm.
-
Hey @ryan, see http://processwire.com/talk/topic/3763-editing-module-info-checks-everything/?p=36825 it was lastpass.
-
You're both right. Just checked on another browser, form works as expected - not filling up options by itself. Found the culprit -> LASTPASS I logged off lastpass and the form worked correctly. I logged in to lastpass and everything got checked. very helpful little bugger. Sorry.
-
I just recently edited the module information on http://modules.processwire.com/modules/page-edit-per-role/ and didn't realize that all Categories and Version Compatibility was all checked and saved it. Good thing @Soma caught it and corrected, but my question is, why does everything get checked when you edit the module info? I think this is alright when you are first adding the module but when you're already editing I would assume that only the options you previously checked would be checked.
-
oh.. woops! that must have been when I updated the info for the modules. I'm pretty sure I set it to the same categories as the Page Edit Per User module. yeah now that I look at it, I see that compatibility has been set for 2.0, 2.1, 2.2 and 2.3. I've only set it for 2.3. I just tried editing the module info and I saw that all categories are checked. same goes for compatibility. Is this something to discourage *editing*?
-
yeah, probably a bit much like this module http://modules.processwire.com/modules/page-edit-per-user/ from which this module was modified from and which I'm pretty sure behaves much the same except that this module applies to roles and not to users So I guess you could pretty much say the same thing for the other module
-
By default, users who can edit/create/add children can publish pages. To only allow them to create but not *publish*, you'll need to go to Access -> Permissions and add "page-publish". Now users who don't get this permission (but have edit/create page permission) won't be able to publish pages, only create. If you delete the "page-publish" permission, the users can now publish again. Now, my question is, are there any other *hidden* permissions that I can use?
-
Page Edit Fold Status Module, Custom Admin themes and PW v2.3+ issue
pogidude replied to pogidude's topic in General Support
yes I checked for JS errors after I read another thread regarding the top submit buttons and js forgot what it was about though. No errors in chrome console though. -
I am using Page Edit Fold Status module, Moderna admin theme and Processwire v2.3. The issue is that when I click on the top save button on any page, my edits don't get saved. If I deactivate Page Edit Fold Status module, the top save button works. If revert to the default admin theme and the Page Edit Fold Status module is activated, the top save button also works. Now, I've also tried using the Ergo admin theme http://modules.processwire.com/modules/ergo-admin-template/ and the same thing happens. Now, I understand that both Moderna and Ergo have compatibility up to Processwire 2.2 only. I'm guessing that the combination of PW v2.3, custom admin themes compatible only to v2.2 and Page Edit Fold Status module is causing this issue. So, my question is, what's new in PW2.3 that could be affecting the top save button when I use these custom themes and the module? More importantly, what can I do to fix this or at least which file should I be looking at?
-
Thanks for this awesome theme Nikola. Love it Just one small thing though. If install the Page Edit Fold Status module http://mods.pw/4Q the top save button doesn't *save* edits any more. I initially thought it was the module that was the issue but when I switched to the default admin theme, the top save button works correctly now. Other than that, loving the theme.
-
Hmmm.. you're right. so, to clarify, the methods Page::editable, Page::viewable, etc.. were all added in the PagePermissions module by calling: $this->addHook('Page::editable', $this, 'editable'); correct? which means, in my module, I could essentially *add* my own method hook to the Page class like this? $this->addHook('Page::pogidudemethod', $this, 'pogidudeSomeMethod'); to which other modules can also hook into and which could also be used like: $var = $page->pogidudemethod(); very coool... yeah, sorry I was only skimming over the modules/threads since I wanted something I could implement quickly. But what you have going here is pretty neat too. thanks!
-
uh, yeah, my next question was going to be about captain hook. In this thread http://processwire.com/talk/topic/371-page-specific-permissions/page-3 there is this code: $this->addHookAfter("Page::viewable", $this, 'viewable'); and others like it. I would assume it would be listed under Page class.. Edit: Nevermind, grepped for it in the files.. I guess I'll just have to read the core lazy me.. sorry, I come from wp where I almost never have to go through core since most of info about functions I need is already in codex.
-
hmmmm.. now that I've seen the thread, seems like I need an "addable" hook, and other permissions, and tests on my setup show that I do need it I'll most likely update this module as I do like the idea of keeping all pages that a role has access to in one place.. aside from poring reading through the source code, is there any place where the hooks I need are documented?