sgt.blikey

It would be helpful to have a bit more flexibility on this field type. What about, instead of any extension, an option for no extension? Use case: storing configuration files in a knowledgebase system. It is a little inconvenient to be required to rename a file or add an extension in order to upload, and once more when downloading. I appreciate it isn't a major headache to have to do that, but it all goes towards usability.

You're right, the hidden version of the field is not populated. The field is populated only after changing its visibility to something other than hidden, and then editing/saving a page. Thanks for clearing that up.

No, I'm not sure of this actually. I've been changing the visibility setting from hidden to something else, e.g. closed. Subsequently, when viewing the page, the field is populated, but I haven't tested whether the value is correct-ish so I do not know whether the field is populated when the page is created or when the attribute is changed from hidden to closed.

Oh, I forgot about that field. That is what I need, but I'm curious about the above.

How do you determine whether the field has been populated? If the field is hidden, where do you view the content of the field? I mean, if a field is hidden and auto-populated, how can you see its value?

Howdy, What am I misunderstanding? I have a date time field and have specified that children of template 'home' should be (reverse) ordered by that field the field should default to todays date input and output formats I have added the field to the template 'basic-page'. When, under field settings > input > visibility, I have set it to 'Closed' the field is populated when a new page is created and the page is ordered correctly under Home. When, under field settings > input > visibility, I have set it to 'Hidden (not shown in the editor)' the field is populated when a new page is created but the page is ordered incorrectly under Home and subsequent reloads of the page tree do not resolve the issue. Changing the option for the field back to 'Closed' doesn't reorder the pages under Home according to the rule. Why is that happening? Nic

Oh, they're in there are they? Okay so I should have: $ grep -R page-edit-created * Thanks for pointing me in the right direction. For pedantry's sake I've gone with: if(!wire('permissions')->has('page-edit-created')) { $permission = wire('permissions')->add('page-edit-created'); $permission->title = 'Edit only pages user has created'; $permission->save(); }

@adrian thanks. I wonder where the names/titles are coming from when populating the form/table in the function beginning here. https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPermission/ProcessPermission.module#L37 protected function getOptionalPermissionsForm() Does this line suggest they exist as pages? https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPermission/ProcessPermission.module#L51 $optionalPermissions = $this->wire('permissions')->getOptionalPermissions();

I would like to check for and enable the predefined system permission 'page-edit-created'. I am currently working in a 3.0.27 installation. When the permission is enabled in the admin, it has a title, 'Edit only pages user has created'. I am using the following code (in the context of a module): if(!wire('permissions')->has('page-edit-created')) { wire('permissions')->add('page-edit-created'); } This creates the permission, but leaves the title blank. Deleting this api created version via the admin restores the title, that is it seems to restore the default version of the permission. Is there an alternative to add, e.g. enable, that enables the permission as defined by the system? Am I checking for its presence correctly? Thanks!

Surprising myself, I have figured out how to hook into Page::addable. class MemberBranchAddable extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Member Branch Addable', 'version' => 3, 'summary' => 'Grant addable access to users on their member page', 'singular' => true, 'autoload' => true, ); } /** * Attach hook to Page::addable * */ public function init() { $this->addHookAfter("Page::addable", $this, 'addable'); } /** * Page::addable hook * * Add children permission is granted based on edit. * If they have edit access, then they can also add children, * but only apply this if the $page->template = 'member' * */ public function addable(HookEvent $event) { $page = $event->object; // If page template is $singular continue // That $singular should come from the // configuration if ($page->template->name == 'member') { // If page is editable and generally can have children, then allow addable if ($page->editable() && !$page->template->noChildren) { $event->return = true; } else { $event->return = false; } } } Which takes care of: And removes the requirement to manually edit wire/modules/PagePermissions.module

An additional specification. MemberGalleries (an index page)Gallery A Gallery B Journals (an index page)Journal 1 Journal 2 Allow, for each member page, one and only one page of template 'gallery-index' and one and only one page of template 'journal-index'. For the Member page, if there exists a child page of template 'gallery-index' and a child page of template 'journal-index' then do not offer 'new' in the page tree options for page Member. Otherwise offer the 'new' option and when the Member has advanced to /page/add/ if there exists a child page of template gallery-index, offer journal-index; and if there exists a child page of template journal-index, offer gallery-index. An extension of the Family > Can this template be used for new pages? Yes/No/One (no more allowed)/One per parent (no more allowed)

As far as I can see it isn't possible to achieve this with the built-in permissions. You'll have to modify the source files. I don't know which files you need to change, but someone might chip in. Given the following tree... Home -- Un-editable Index Page 1 ---- Editable Child Page A ---- Editable Child Page B -- Un-editable Index Page 2 ---- Editable Child Page C You will have to add clauses to the appropriate files that allow for a user with a role.. To move/sort Child Page A/B underneath Index Page 1 To move Child Page A/B to be a child of Index Page 2 etc. You might reasonably expect that the page-edit attribute applies only to the page content, but I don't think it does.

@Olli I am doing the same (with the code from post above #6) I get my child pages $posts = $page->children; I loop through the posts: foreach($posts as $p){ $pbody = $p->wordLimiter("body", 100); echo($pbody); } & this produces the desired output.

That's weird, I was looking at this site about a year ago. What a metamorphosis.

Note. I think inserting images from within CKEditor is being managed by ProcessPageImageSelect.module, which is using ProcessPageList.module to build a list of pages to select an image from, which I think is using haspermission("view") to construct a tree. Something like this: https://processwire.com/talk/topic/6315-processpagelist-to-hide-some-pages/?hl=processpagelist

Thank you so much. That's set me on the right path: public function init() { parent::init(); // always remember to call the parent init wire()->addHookAfter('ProcessPageEdit::loadPage', null, function(HookEvent $event) { $page = $event->return; // loadPage() does return the page if($page->template->name == "user"){echo($page->name);} }); }

I see, that's helpful. I'm exploring at the moment. My intention was to have processwire echo to me something like "Yes, this user has role X", or "No, this user does not have role X". I defined(?) this hook: wire()->addHookAfter('Page::render', $this, 'displayMessage'); i.e. "after this page has been rendered, execute displayMessage", and I was hoping that my funcition would tell me which template is in use, and (mistakenly assuming that it would return the user template) I would then be able to ask further questions and get the data I wanted.

When on this page (editing a user): How does one access the data that is being displayed here from within a module? For example I might want to test whether 'of the roles presented here, which are selected/not selected'. I thought that I would need to test whether the template=user, but the template=admin. public function displayMessage(HookEvent $event) { $p = wire('page'); echo($p->template->name); } Why is that?

Further issues with this include and may not be limited to: Template access settings are not honoured. These are the settings applied to the alternate user template 'member' for user 'selfedit1' with role 'member'. This is what the user 'selfedit1' is offered in the page tree. i.e. no opportunity to edit the page, or add a child I'm just saying. I don't think I did, but maybe I set it up wrong. I appreciate the time you've taken considering all of the above, thank you for that. While it might take me months to create a module that can do what I've described above, I'm perfectly happy with that temporary limitation and as described I can manually achieve what I want. The site that uses this scheme does not have so many 'members' that building it manually is an onerous task; I can perform the actions I need to in about an hour probably and, in the mean time, hobble on trying to build a module that could do it for me. I don't think there is anything 'wrong' with what I've described, at least no one has pointed out any failure in the design. Cheers, Nic

Thank you, yes. I'd seen the former, not the latter.

That is quite alright, I'm not seeking examples. On the surface that seems useful, but additional work is needed in order for it to help with the above. For example, without further modification it isn't possible to change the "Created by user" setting, on a page created using that scheme, to a user created under an alternate branch because the alternate branch is not offered for selection. So, on the other hand:

Can a module accomplish the changes and actions I've described?

No, I have to repeat the same action x times (where x is the number of users I wish to have manage their own branches) in order to achieve what I want. I have to repeat the same action on each user I wish to have manage their own branch. It replicated what I have been doing manually as descibed in my original post, and doesn't remove the requirement to make manual repetitive changes. If I use this module I must still repeat steps I would like to automate, as descibed in my original post. Yes, the scheme defined in my original post described a system in which the superuser assigns a role to a user and the required page/branch (and it's associated permissions) is created. The AdminRestrictBranch does not do what I described in my original post.

I have tried the AdminRestrictBranch module. I used the following options: How to match user to branch: Specified Branch Parent Branch edit exclusions: I selected (using the example above) Section X Next I created a branch parent for each user, 'Member A', Member B', 'Member C', etc using an appropriate template. Then I visited a user's profile and selected the appropriate branch, i.e. User:'Member A' - Branch:'Member A'; and repeated that for all users I wished to have manage their own branch. Are those the settings/actions you would expect in order to replicate what I've described?

I think that module may be too broad for my needs. What I've described above is, apart from the edit to wire/modules/PagePermissions.module, mainly automation. Prior to the introduction of the page-edit-created permission I would have required a template per user to achieve the same thing (as my vapourware above). With this design the requirement is cleaner, thanks to the page-edit-created permission. Once the structure has been set up a user manager only need assign the 'member' role to a user and the job is done. It appeals to me because I don't have to consider anything other than whether a user is a 'member'; any access permissions assigned to other roles, to other templates won't interfere; and a user having the role 'member' will not interfere with permissions granted to them by any of their other roles. One other thing; the design is based on the idea that a user owns an object, not that a group owns an object, which is a distinction worth mentioning I think.