[development] Perm for setting RTBC - Re: RTBC - how does it work?
drupal at dwwright.net
Mon Jul 2 12:50:00 UTC 2007
On Jul 2, 2007, at 8:22 AM, Augustin (Beginner) wrote:
> Well, there is a permission for "set issue status patch (ready to
> in ?q=admin/user/access .
> Why not make good use of it?
In theory, I'd support this. The per-status permissions have always
struck me as a bit weird, but this is actually a pretty reasonable
use case for one of them. ;)
There are a few minor bugs in how these permissions work that we'd
have to fix before this really worked. For example, if we
implemented this, once a blessed reviewer set to RTBC, if anyone else
without the perm tried to followup, the status would revert. We need
to fix the perms so that even if you don't have permission to move it
into RTBC in the first place, if it's already there, you can leave it
there. This is trivial, and there's already an issue open about
this, but just wanted to point out there might be a few minor gotchas
like this as we start to implement role-based issue status
functionality. Nothing that can't be solved, of course.
HOWEVER, the big problem here is that these permissions are site-
wide. And I'm not sure we want the same restriction to apply to who
can RTBC in *all* issue queues across the site, do we? I presume
people are imagining this for the core queue, but not all queues.
So, that's a big problem. Either we accept that it's site-wide and
basically make it harder for people to RTBC non-core issues, or we'd
have to do a bunch of work to make these perms somehow per-project,
not site-wide (og_project.module, anyone? ;) -- just kidding).
So, if people are going to +1 this proposal, please understand it'll
basically have to be site-wide, and that we'd have to find ways to
cope with that across all the contrib issue queues. I don't get the
sense that most contrib issue queues actually make much use of RTBC,
anyway. It seems rare to find non-core queues where it really
matters, or where there are a pool of reviewers and testers outside
of the maintainers themselves. And in the rare cases where that's
happening, I'm guessing the maintainers of those contribs would be
happy to have the same pool of qualified reviewers with the perm to
All of that said, I still think this is worth seriously considering.
It certainly won't solve all the problems, and it might create a few
of its own, but overall, I think this is a reasonable suggestion.
More information about the development