Jump to content

sgt.blikey

Members
  • Posts

    49
  • Joined

  • Last visited

Posts posted by sgt.blikey

  1. 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.

  2. 7 hours ago, Robin S said:

    Are you sure of this? I tested it quickly and it seems to not populate the field when set to hidden. If the inputfield is hidden then I expect its render method is never called so no default value is entered into it.

    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. :-)

  3. 35 minutes ago, Robin S said:

    Are you sure of this? I tested it quickly and it seems to not populate the field when set to hidden. If the inputfield is hidden then I expect its render method is never called so no default value is entered into it.

    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.

  4. 14 minutes ago, Robin S said:

    Is there a difference between what you're wanting to do with this field and the "created" property that exists by default when adding a new page? Because if your field is hidden then nobody could ever edit it so it would always remain identical to the created datetime. So could you just sort your pages by "created"?

    Oh, I forgot about that field. :-)

    That is what I need, but I'm curious about the above.

  5. 8 minutes ago, Robin S said:

    Are you sure of this? I tested it quickly and it seems to not populate the field when set to hidden. If the inputfield is hidden then I expect its render method is never called so no default value is entered into it.

    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?

  6. 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

  7. 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();
    }

     

    • Like 1
  8. @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();

     

  9. 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!

  10. 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:

    Quote

    Members A, B and C can add, edit, sort and delete children of their page Member A/B/C. They may also edit their page Member A/B/C. Without any additional roles they have just ‘view pages’ access elsewhere.

    And removes the requirement to manually edit wire/modules/PagePermissions.module

    • Like 3
  11. An additional specification.

    • Member
      • Galleries (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)

  12. 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.

  13.  I see, that's helpful.

    Depending on which class and method you're hooking there are different ways on retrieving the actual edited page, which is probably more of your interest.

    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.

  14. When on this page (editing a user):

    post-2173-0-44121700-1449787026_thumb.jp

    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?

  15. This sounds like a bug / oversight - perhaps you should file a Github issue about this.

    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'.

    post-2173-0-21212100-1449741175_thumb.jp

    This is what the user 'selfedit1' is offered in the page tree.

    post-2173-0-00040100-1449741517_thumb.jp

    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

  16. Modules can accomplish almost anything - if you are willing to make a start, I am sure you will get plenty of help if you need it. There might be something useful in this thread: https://processwire....me-as-username/

    You might also like to look at the way the EmailNewUser module triggers an email when a new user is created - you might be able to use that as a starting point for modifying to create the member page instead.

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

    What about this setting in Advanced Mode:

    because the alternate branch is not offered for selection.

    post-2173-0-74378400-1449739191_thumb.jp
  17. Sorry my answers aren't complete with examples today - lots to do and not much time  :)

    That is quite alright, I'm not seeking examples.

    But, what I would do is use the "Multiple templates or parents for users" ability instead: https://processwire....rents-for-users

     

    That way the member page is the user page, so one less thing to create and maintain.

    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?

  18. I guess my question for you, is does it work as you want?

    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.

    Seriously though, I think it should, but if the editors need to directly edit pages under Section X then you would need to use the "Editing Only" option, so that the page tree view is not actually restricted.

    I have to repeat the same action on each user I wish to have manage their own branch.

    With that setting, I think it should work as you described - how did it work out?

    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.

    Was there anything that didn't work as you need?

    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.

  19. 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?

  20. 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.

×
×
  • Create New...