Here's a proof of concept patch that adds a role permission for pathauto override. If a user has permission to create paths, but does not have permission to override paths, this patch hides the URL path settings fieldset by changing it and it's child elements to 'value' types. Any existing values pass through to the standard path and pathauto submit handlers, and paths are created or updated as normal.

Now I can create roles that can automatically create paths according to a certain pattern, and the role's users can not override the pattern.

The override permission needs to be true to maintain backward compatibility. To complete this patch, an update handler should be added that enables this permission for all roles. Admins can selectively disable it as needed.

If I can get buy-off on the idea, I can complete the patch for 5 and 6x branches.

CommentFileSizeAuthor
#5 pathauto_allow_override.patch2.62 KBcriznach

Comments

dvinegla’s picture

dvinegla commented
Status: Needs work » Postponed (maintainer needs more info)

Where is the patch?

Freso’s picture

Freso commented
Version: 5.x-2.x-dev » 6.x-1.x-dev

Uhm. What's the idea of having the "create alias" permission if you're not actually able to use it (ie., use a manual alias instead of what is being generated by Pathauto)? I'd really like a use case and/or a workflow description, describing the new behaviour when a user has "create alias" permission, "create alias" + "override pathauto" permission, and just the "override permission". Preferably with a note on how the three cases are different from now.

(Also, all new stuff that changes behaviour will go into 6.x-2.x (see New 6.x Releases on the Horizon), so no need to worry about getting it to work on 5.x.)

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Postponed (maintainer needs more info) » Active

Thanks for proposing this idea. Mostly I agree with Freso - I'm not sure I see a benefit or difference from the core "create alias" permission and look forward to hearing your thoughts on that, criznach. (I also agree that this should be targetted for 6.x-2.x if we agree on the use case).

criznach’s picture

criznach commented

I think the project team needs to add a "where's the patch" button to each issue queue. Sorry, here it is...

The idea is that... I want to automatically alias paths for certain users and I don't want them to be able to override it.

There was previously no way to do that. Unfortunately path and pathauto are separate, which complicates the situation. If I disable "create alias", pathauto does not automatically create the alias.

So...

"create alias" without pathauto = works and looks the same
"create alias" and "allow override" = works and looks the same
"create alias" but not "allow override" = automatic alias created/updated according to pathauto settings, but with no path UI on edit or create pages
no "create alias" but "allow override" does nothing. The role can't create aliases anyway.

[edit] and a better use case...
Not so bright editor should only be able to create content under /shop/ folder. Editor should not be able to override paths of their own content. Normal editors can be trusted to create whatever paths they want.

And yes, I agree that 6.x is the way to move ahead, but I need this for a client that is not using 6.x. It made little sense for me (in this case) to create a 6.x patch that I can't use If the maintainers might not accept it. If I can't get buy off on the idea, I'll move it to a band-aid module for 5.x and call it a day. If you think this is a great idea, I can build the 6.x version and refine that.

Thanks,
Chris

criznach’s picture

criznach commented
StatusFileSize
new pathauto_allow_override.patch2.62 KB

Hmmm... Patch got lost again?

Freso’s picture

Freso commented

If I disable "create alias", pathauto does not automatically create the alias.

This sounds like a bug to me. If I'm not much mistaken, the current behaviour should be to always use Pathauto when creating content to generate aliases for it - but allow for users with "create alias" permission to specify a custom path (ie., overwriting Pathauto's default behaviour).

Greg?

criznach’s picture

criznach commented

I tested this yesterday but I'm not sure what versions I was using. Unless I missed something, the alias wasn't created.

I just tested on a fresh install of 5.7 and pathauto 2.2 and it worked as you said. I need to double check on the site in question.

A learning experience... :)

criznach’s picture

criznach commented
Status: Active » Closed (fixed)

I found the problem...

I had overlapping permissions.

"shop admins" did not have permission to "create path aliases", but "authenticated users" did. So the shop admins inherited the permission. I didn't see it because I was editing just this role's permissions, not all roles at once.

Case closed. Sorry for the distraction. Carry on...

Freso’s picture

Freso commented
Version: 6.x-1.x-dev » 5.x-2.2
Component: User interface » Code
Category: feature » support

Haha. It's alright. Glad you figured it out. :)

christiaan_’s picture

christiaan_ commented

Thank you for a great patch. To be able to hide the Create Path Alias form item on a node based on roles is very handy.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

It respects the "create path alias" control, so...just remove that permission from the role and the whole form area goes away.