One of our clients wanted to open the redirect module up to users of a particular role, but didn't want them to be able to edit his redirects (and certainly not delete them).
So I started creating a separate module to achieve this, but because the redirect module already saves a uid, it ended up being a very simple module. Therefore I also just patched the dev code.

CommentFileSizeAuthor
#5 redirect-access_own_redirects_only-2220061-5.patch3.07 KBSneakyvv
#1 redirect-access_own_redirects_only-2220061-1.patch3.5 KBSneakyvv

Comments

Sneakyvv’s picture

Sneakyvv commented
StatusFileSize
new redirect-access_own_redirects_only-2220061-1.patch3.5 KB

Patch attached.
It adds a new permission and alters the redirect_access function to compare the redirect's uid to the account's uid if the user (only) has this new permission. I also fixed the fact this function is not allowing other modules to override the access. At least I think that was not intended, because by returning TRUE if the user has the "administer redirects" permission calling the hook_redirect_access is pointless, I assume.

Note that I also incorporated the patch from #2135577: uid is always set to 0 when a redirect is created, since the uid was not being saved (anymore).

Sneakyvv’s picture

Sneakyvv commented
Status: Active » Needs review

Triggering test bot

Sneakyvv’s picture

Sneakyvv commented
Related issues: +#2135577: uid is always set to 0 when a redirect is created
pere orga’s picture

pere orga
Primary language Catalan
commented
Status: Needs review » Needs work

Patch does not apply anymore and should be updated

Sneakyvv’s picture

Sneakyvv commented
Status: Needs work » Needs review
StatusFileSize
new redirect-access_own_redirects_only-2220061-5.patch3.07 KB

patch updated so it applies to latest dev version

chris matthews’s picture

chris matthews commented
Status: Needs review » Reviewed & tested by the community

The patch in #5 is 3 years old, but still applied cleanly to the latest 7.x-1.x-dev and after reviewing/testing works great for me so changing the status to RTBC.

Checking patch redirect.module...
Hunk #1 succeeded at 71 (offset 1 line).
Hunk #2 succeeded at 105 (offset 1 line).
Hunk #3 succeeded at 693 (offset 59 lines).
Hunk #4 succeeded at 710 (offset 59 lines).
Hunk #5 succeeded at 728 (offset 59 lines).
Hunk #6 succeeded at 1628 (offset 178 lines).
Applied patch redirect.module cleanly.
pifagor’s picture

pifagor commented

  • pifagor committed 84a4b2f on 7.x-1.x authored by Sneakyvv 
    Issue #2220061 by Sneakyvv, Pere Orga, Chris2, pifagor: Add permission...

  • pifagor committed 0a556c9 on 7.x-2.x 
    Issue #2220061 by Sneakyvv, Pere Orga, Chris2, pifagor: Add permission...
pifagor’s picture

pifagor commented
Status: Reviewed & tested by the community » Fixed
dww’s picture

dww
we/he/they
commented
Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Fixed » Patch (to be ported)

What's the deal with committing new features only to D7 without adding them to D8? Is that the intention of all of the redirect maintainers? Seems like a fairly confusing / bad idea. Drupal core, and nearly every contrib module I know of, doesn't do this. It seems totally bizarre that the "old" version, soon to be obsolete, is getting new features that aren't available in the mainline development branch.

Shouldn't we add new features in D8 first and backport to D7?

At the bare minimum, if we're adding new features to D7, let's set the issue status to 'Patch (to be ported)' and move the version to D8 so at least we can keep track of the divergent feature set.

Thanks,
-Derek