Inherit access settings from parent forum / container

A lot of interesting ideas! This is unlikely to happen for D6 anymore, but it has potential for D7. Maybe not 7.x-1.x but 7.x-2.x, because porting is hard enough, and adding new functionality at the same time can cause delays and confuse users.

b) is too complex and unmanageable. The template feature is intended to be static (provide a starting point for settings on a newly created or updated forum). It remains useful as it is.

3) this is not NTFS, we have to KISS

I went through an interesting thought process here. At first ac1) made a lot of sense and I thought 2) was way too complex and I failed to see the benefit. After all, if you want the parent to control access, then set to INHERIT...

I even looked at some three-state checkbox implementations and found a nice one here.

However the three-state checkbox doesn't give us all the information we need in this context. If it's set to INHERIT, then we don't see what we're inheriting. We'd have to move upwards in the forum hierarchy, possibly multiple levels, to find out, for each checkbox. To avoid this nuisance, we need four display states (including INHERIT-yes and INHERIT-no).

After some more thought it dawned on me that 2) is probably more appropriate, because it takes the hierarchy into account. We just need to describe it in a less technical way.

Already now, we expect maintainers to manually arrange View permissions in such a way that they don't break the hierarchy, i.e. that users who have View access to a given forum should also have View access for all the ancestors of that forum (or at least See access, in the case of containers). That's really the only reasonable way of setting this up, but we don't enforce it.

I'm not sure how it looks if you don't follow that implicit rule, I've never actually tried it, but I think it should work somehow...
 

Let's explore the implications of 2):

1. We only have two states to set: YES (which implies INHERIT) and NO.
2. In the case of YES, we still need to display what the current result is, depend on the nearest non-inheriting ancestor, i.e. we need three display states, including YES-yes and YES-no (= overridden by a NO somewhere in the ancestors chain).
3. So, YES is not really YES, but rather INHERIT, assuming the root is YES.
4. That brings us to INHERIT-yes, INHERIT-no, and NO, with each widget only offering one of the INHERIT states (plus the NO state) at any one time.
5. I think this makes sense for View, but View does double duty as Administer right now, and there it doesn't work, because you'd typically want to give Administer access to a subtree, but not to the root of the forum hierarchy. There, we need to be able to change an inherited NO into a YES somewhere further down in the hierarchy — we're back at three clickable states!
6. Administer should have YES, INHERIT-yes/no, and NO.
7. Create, update, and delete work in the same way as Administer.
8. Only View should be restricted to INHERIT-yes/no and NO, with the additional twist, that View is a prerequisite for all the others.
9. Then again, I hate unnecessary, artificial restrictions. It might make sense to set View to NO in the root and voilà, we need YES for View, too...
10. There, we have come full circle!
11. How can this degrade gracefully in the absence of JavaScript? We probably need three radiobuttons like
    ( )Y ( )y ( )N   or   ( )Y ( )n ( )N
    depending on whether the nearest non-inheriting ancestor provides YES or NO.
12. In a way, this non-JS version provides even more information because you can see what INHERIT would mean even if you don't select it, but the resulting grid would look awfully crowded. All three states of the JS version should probably somehow indicate the state of the parent forum.
13. So we'll probably end up with two different widgets (2 times 3 bitmaps), depending on what the parent provides.

Please slow down a bit :-)

In addition we could add a 4th option "disallow for all children", which would cause any "allow" value of any child to be treated as "inherit" in access checks. I think we should wait with that.

No, this would cause a support nightmare. People would trip over themselves and come here for support. FA needs to remain easy to understand and use.

Access check implementation:

No "disallow for all children", but we'd probably need to denormalize the data to avoid multiple queries.

An interesting detail:
What if a user has two roles, "joker" and "vip". "vip" has access to the parent, but is not allowed to see the child. "joker" has the child set as 'inherit', but is not allowed to see the parent.
Now the access check function looks at the parent (which returns "yes, access granted"), and at the child ("inherit"), so it will grant access.
A user with only "joker" or only "vip" role would not have been given access to this forum.

Yes, this is a tricky situation. I think the intention here is to not give access, so it should not be given. This means that the ancestors chain needs to be evaluated per role...

I agree it is desirable to visualize the parent state in some way, independent of the current checkbox state. Simplest would be a piece of text saying "parent: allowed", appended to the role name.
I think this is a design detail, and we should focus on the structural aspect at first.

Thinking about UI design helps to clarify the structural design. This is not a per-role thing, but per-role-and-access-type.

A reasonable no-js fallback would be a
dropdown. I think this would be less clutter than radios. The script would turn the dropdown into an icon toggle.

When you run update.php, do you check which hook_update_NNN() functions will run? Do you find it easy to find the dropdowns that have a number in them rather than whatever the usual text is if there's no update? Now imagine this not in one column but four or more. And we'd lose the parent indicator for the YES and NO states.

This is unlikely to happen for D6 anymore, but it has potential for D7.

That's a pity..
Honestly, noone forces you to follow the Drupal core release management strategy in a contrib module. You can develop or backport as many new features for D6 as you want. That's what I will do for my contrib modules for at least for the next 6 months, I guess. The "freeze after release" is a pita imo.

It's simply a question of priorities and available time. I'm plenty busy for many months to come with porting my modules to D7. This is the top priority, certainly for Forum Access. For FA for D7 this includes broad coverage by Simpletests. After that, I'll have time for new features. New features always have to go into the latest major version. We can't have users who upgrade from D6 to D7 lose features that they have come to depend upon. This would block their upgrade path.

When this is implemented in 7.x-2.x, you are certainly welcome to backport it to 6.x-2.x (if you agree to maintain and support it). However, you'll need to backport the Simpletests to 6.x-1.x before we can create a new 6.x-2.x branch from it. We can expect some help with testing 7.x-1.x, because people are itching to move to D7, but otherwise we're pretty much on our own, which means we have to lock this down with Simpletests, or it will kill us if we touch it. I simply don't have the time or interest do any of this D6 work myself.

Btw, another nice thing would be a hook for other modules to change forum access settings. Maybe a forum_access_alter(), that is called at the end of forum_access_access() ?

No, support nightmare again. If another module wants to interfere, then it has plenty of possibilities within the node access system, which can be closely monitored by devel_node_access. Also, bulk operations are controlled through the {node_access} table and the results obtained from there need to be consistent with the results for single nodes.

A permission to control who can see the forum_access checkboxes when editing a forum. Sometimes we want a user to be able to create subforums and choose moderators, but not do any role-based configuration.

I think this is too specialized. FA has a broad audience. I cannot add features that would be useful for 2% and add unnecessary complexity for the other 98%. Also, the cost of adding a feature is much higher than simply implementing it: it needs to be maintained, ported, supported, etc. And because of the additional complexity, it increases the burden of maintaining, porting, supporting, etc. all the other features that are already in the module.
 

I see you're well-versed with creating widgets (Multicrud). A configurable three-state checkbox would surely be useful for Drupal. Would you be interested writing such a module?

I don't know how hard it is to create a new widget, but if this were a module that could just be dropped in and provide something like a '#type' => 'tristate', then I'm sure a lot of other modules would start using it, and it might even find its way into core as a new built-in widget. As you can see on Google, there's certainly interest, and having ONE tristate (or nstate? where n includes 2, for fancy checkboxes) for Drupal would certainly be better than everyone wasting their time trying to roll their own.

For the fallback we need something that
* goes into one table cell
* takes little space, a single short line of constant length
* aligns into columns
* can easily be scanned (having some additional text which only applies if a certain dropdown value is chosen clearly fails this criterium)

A row of radiobuttons fulfills these requirements. You can easily scan a long column of these and immediately recognize the ones where, say, the bullet is in the middle. This is not possible with dropdowns, because you have to decipher the content of each.

Four radiobuttons where one of the two middle ones is disabled might be even better. Something like
Y( )(x)(o)( )N
which would mean "inherit the NO" (the x meaning disabled).

Great! A green checkmark and a red X are pretty universal, I guess. The third state could be a blue question mark (like ZoneAlarm).

I'm pretty challenged with art design, but I've tried to create something along of what I'm contemplating for the special use case here with FA (see attachment). The small icon in the top left corner shows the parent state (what you would inherit if you decided to inherit), and the blue arrow means that you're actually inheriting it. So I'd be using three out of the six icons, depending on the state of the parent.

A cute 6-state could show the six sides of a die. Probably not of immediate value, but immediately recognizable.

A number of smileys going from :-D to :-( could be another example.

An example for a 2-state might be thumb-up and thumb-down.

This should be very customizable, i.e. it's desirable to be able to specify n pics as well as n corresponding values, and there should be a way to templatize it, i.e. if I need 20 widgets of the same type, I'd like to be able to specify it once and give it a name that I can reuse any number of times on the same page. An added plus would be if this were somewhat efficient output-wise, i.e. the configuration would appear only once in the html/css/js. The number of templates shouldn't be limited.

The ability to disable it in any state would be useful, too.

That's for the client to decide. Why would you want to artificially limit the number of states, just because you think it's good for your client? Patronizing software is infuriating...

Maybe the right mouse button could cycle backwards?

There is no natural "right" number at which cycling needs to be replaced by some other mechanic. We just can't know what the client prefers, and if a piece of software makes arbitrary decisions for me then I feel patronized (sorry, hot button)...

I don't think the 2's are significantly more difficult than the 1's, so there's no point thinking about the 1's.

Alternative mechanics — I don't really know. Press and drag maybe? Kind of like UpDowns that work like sliders?

BTW, have you reserved your preferred name in cvs yet?