Closed (fixed)
Project:
Redirect
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
9 Nov 2016 at 11:47 UTC
Updated:
23 Feb 2017 at 23:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
scott_euser commentedThis patch separates the settings page into a new permission and adds a hook_update_n to maintain existing access for sites with this module already installed.
Comment #3
scott_euser commentedComment #5
berdirWorks for me but needs a reroll.
Comment #6
scott_euser commentedHmmm strange it is stuck on 'Running' for a few hours now. Will see if switching it to needs review will jolt it back to life.
Comment #8
scott_euser commentedUpdated patch to match changes since patch originally submitted (no change besides hook_update_n number), should apply now.
Comment #10
scott_euser commentedUpdated with changes to test permissions to match new permission change
Comment #11
scott_euser commentedComment #12
berdirThe new 404 module has an ignore feature that redirects to the settings page to configure the ignore filter. We probably need to limit that to users with settings permission.
Also, updating the description of the existing permission to clarify that you can Manage URL redirects but not change the settings or so.
Comment #13
scott_euser commentedHmmm I am not sure how to handle the access in the Redirect404Operations views field. Does it need to have add and ignore placed into two separate fields? It seems the access method in there is an all or nothing for the contents of the render (or am I looking at it wrong?). Am I right in assuming it is not appropriate to wrap the Ignore operation in an if statement with something like:
Stepping back a bit, perhaps a site editor who is not allowed to change the global redirect settings should still be allowed to ignore a 404 URL. I imagine that would be a bit more complicated since you use the redirect global config to handle ignores (redirects = content and redirect 404 ignores = config?).
Re the permission descriptions, is this more accurate:
Comment #14
berdirI think a if condition around one of the two links is perfectly, depending on how it is set you can maybe even use #acess.
I think preventing ignore for now is fine, we can still extend it later.
Comment #15
scott_euser commentedSounds good thanks! I couldn't see how to make access work on a single link as both links get added to the same render element (putting #access on the link has no effect) so I did go with the if statement. Added in the user via dependency injection. Also updated the 404 routing yml file accordingly.
Comment #16
scott_euser commentedIf you are happy with this one after the above discussion, okay to mark as 'reviewed and tested by the community'.
Please let me know if you have any further issues or blockers on this that you'd like me to address.
Thanks!
Scott
Comment #17
stefanos.petrakisNeeded a tiny reroll because of a function naming conflict (redirect_update_8106 already taken).
This came from the latest alpha release, 8.x-1.0-alpha3 (commit: d1eaf7c7a9d12fdd496e7c4ded094daf3e2ac552).
Comment #18
berdirNote that if you had this patch applied then the other update function wasn't executed for you, and you will need to make that configuration change/cleanup by hand.
Comment #19
scott_euser commentedSounds good thanks!
Comment #21
berdirThanks, committed. Sorry for the delay.
Comment #22
scott_euser commentedThanks and no problem!