Closed (won't fix)
Project:
Forum Access
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
20 Nov 2011 at 19:47 UTC
Updated:
1 Feb 2015 at 18:49 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
salvisPlease post a screenshot of what this would look like.
Comment #2
djg_tram commentedWith the caveat that it's not English...
Comment #3
salvisAre you enumerating all roles? That doesn't scale well...
One of my sites has over 20 roles, and it's a small site with less than 200 users.
Comment #4
djg_tram commentedYes, that's true. An alternative would be to put them into a list, each role into its own line. Easier in some respects but could make the table rather long. Also, in a settings dialog, you could decide which roles to display, not all of them might be really interesting here (eg. you can leave out admins if they always have every right, anyway). I also thought of abbreviating the role names forcibly. At any rate, it's a suggestion that works well on one or two sites I currently use it on...
Comment #5
salvisNo, if this wraps to more than one line, then the "overview" in "forum overview" gets lost.
I see its usefulness on sites with very few roles, but it's not of sufficiently general interest to go into Forum Access directly. However, if you manage to cast it into a self-contained module then it could go in as an optional add-on.
Let's see what the testbot says about your patch; I'm sure it would prefer a single-file patch, just like the humans...
Comment #7
djg_tram commentedYes, you were right. But with icons and stuff, I'll roll it into a separate module and let's see that. Actually, this also would take care of its settings possibilities, to specify which role, to decide in which format...
Comment #8
djg_tram commentedWell, how's about this one?
Has its setting on the Settings page of the forum, two styles now and you can select the roles you're interested in.
Comment #9
salvisPlease don't zip your code — no one will look at it if you hide it inside an archive.
See http://drupal.org/patch/create and make sure you have Unix-style line endings.
Set the Status to 'needs review' to activate the testbot.
Comment #10
djg_tram commentedBut this is not a patch but a complete, standalone module. I didn't expect the testbot to test it as if it were a patch...
Comment #11
salvisAh, sorry, I don't see what's inside.
Even if it's a complete module, you can still put it inside the forum_access directory and create a single-file patch (including the binary icon files!) from it. The testbot will do some useful preliminary testing, and the patch format will let us look at your code in the browser, comment on it using Dreditor, monitor its progress, install and uninstall it quickly, and eventually commit it as a patch.
Comment #12
djg_tram commentedLet's see. Created as per the instructions I could locate here on Drupal.org. SmartGit is not that smart, actually... :-))
Comment #13
salvisAh, passed perfectly and applies nicely. I'll have some minor comments later, but it's looking pretty good.
@djg_tram: What are your intentions for this module? Would you like to release it as a module of its own or contribute it as an add-on to the Forum Access project?
Anyone else care to take a look? Please comment!
Comment #14
djg_tram commentedTo contribute, for sure. It's a small one to start with, and it's linked so strongly to FA that there would be little point in making it standalone.
As far as possible issues are concerned, I really hate the idea of duplicating complete functions from core. But with draggable tables, it still seems the only way to go.
Comment #15
gbyteWas getting
Notice: Undefined index: tid in forum_access_show_rights_form_forum_overview_alter()Changed
$tid = $form[$key]['tid']['#value'];on line 39 to$tid = $form[$key]['#term']['tid'];, now the $tid is always available. See attached patch.Works very well for me now, would love to see this commited. Doesn't have to be a module within the forum access suite - I think it can be integrated straight into the main module, as this is only invoked on one form and doesn't eat resources otherwise. Thanks djg_tram!
Comment #17
gbyteNot sure why it failed, applies cleanly here. Maybe because of the image files?
Comment #18
salvisThis doesn't make sense. If you're creating a new file, it cannot just "differ". In cases like these you should create (and post!) an inter_diff.txt that shows the changes between the two patches, then you would have seen the problem immediately. But...
AFAICS this only works if you have very few roles, and you are the second person (besides the OP) showing interest in this functionality in three years. This means it's not of general interest, and committing it would add a maintenance burden with very little benefit. Sorry...