Add permissions for showing groups on registration form and hiding from directory

And as promised, a 4.6 version.

OK. I'll take the patch, but I don't feel that swell about it. I fear that each implementation has its own peculiarities and we'll have preference hell soon. But this one is pretty confined so lets do it.

I'm not so keen on the permission names. I has to look at the code to see what they meant. I saw 'show groups on registration form', and I figured that applied to the registering user, not the group admin. how about 'add groups to registration form' and 'add groups to group directory'? note the positive in the last one. i made a pledge once to always use postitive when naming variables and permissions. variables like 'hide' alawys end up with 'not hide' and thats a pain to mentally parse.

after you make these changes, feel free to commit.

-moshe

Cool, thanks for the feedback, Moshe!

I tend to agree about positive permission names, so I'll make that change to the registration form one. Good call. However, the default behaviour for the groups directory is TO have groups listed there. The "weird" case is to NOT list a group in the directory. Therefore, I used the word "hide" there rather than "show" or something more uplifting ;) because I think it's more appropriate in this case.

If you still think it should be called "add" and the behaviour should be changed so that groups are hidden by default, we can do that, but I think maybe I didn't explain it well enough the first time and there might be some miscommunication on that permission's intent.

Or, alternately, can you suggest a means of accomplishing this without adding the permissions that doesn't involve og module hackage (esp. in 4.6, where we don't have the luxury of hook_form_alter())? I agree that adding permissions for every use case could become hugely tiresome and daunting.

i can't think of a good way.

"If you still think it should be called "add" and the behaviour should be changed so that groups are hidden by default". yeah, thats what i'm thinking. please add a line to the readme encouraging admin to grant this permission widely. it sucks that we can't install a module and default some permisisons to TRUE.

I will do some thinking on this and not commit either change for now... I'm not really happy changing the default behaviour of the directory in that way, especially for such a little thing in the grand scheme of things.

webchick - we need this for groups.drupal. if you get a chance, please update.

i'm still OK with the positive permission names for both. i don't think the effect is as bad as you described. if you have permission to put your group in the directory, we should default the checkbox to TRUE. if not, you don't even see the checkbox.

> if you have permission to put your group in the directory, we should default the checkbox to TRUE. if not, you don't even see the checkbox.

Right... but when you don't even see the checkbox it should set it to TRUE, right? To retain current behaviour, where all groups (unless otherwise specified) are in the directory?

But then isn't that "add group to directory" permission name confusing if groups are already added to the directory automatically? Aren't we really saying something more like "control group visibility in directory" ? Is that positive enough? ;)

Oy. Maybe permissions are not the right way to solve this ... This is starting to sound like our settings for determining the visibility of a node. those are:

Visible only within the targeted groups
Visible within the targeted groups and on other pages
Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Public.
Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Private.

So lets translate those to the current problem:
New groups don't appear in the group direrectory
New groups always appear in the admin directory
Group creator chooses whether her group appears in directory. Checkbox defaults to *in directory*.
Group creator chooses whether her group appears in directory. Checkbox defaults to *not in directory*.

Like the Public checkbox, node admins should always see this checkbox.

Any comments on this? I'm not certain my thinking is clear. I expect that I will take over this issue at least for 4.7/HEAD since I know how thee visibility thing works.

Hm. Maybe. I don't think it needs to be that refined though:

New groups don't appear in the group direrectory < this would be a kind of useless setting, imo, because when you click the breadcrumb for "groups" it wouldn't show anything in there. And chances are you want at least _some_ groups in the directory, even if it's only a couple for help/support.
New groups always appear in the admin directory < not sure about this either. Chances are you might have one or two odd groups that are 'private' or 'admin' groups, so the ability to choose is rather imporatnt.
Group creator chooses whether her group appears in directory. Checkbox defaults to *in directory*. < this is what I would advocate; by default, groups have this setting checked so they would show up in the directory.
Group creator chooses whether her group appears in directory. Checkbox defaults to *not in directory*. < this might be worth having in a situation where all groups apart from a couple help/support ones are private

I think this could be resolved by:

1. Adding a "change group visibility" permission. It's positively named, and you can restrict who has the ability to create "secret" groups
2, (if you feel this is warranted) A setting in administer >> settings >> og of "directory checkbox defaults to true/false", but make the default true, so stuff shows up in ?q=og

Um. Ooookay. Half my post got eaten. :P

New groups don't appear in the group direrectory (this is a pretty useless setting, imo; if no groups appear in groups directory, then the "groups" breadcrumb to lead you back to ?q=og shows no groups which would be really confusing. And even if you're a privacy freak about your groups ;) chances are you're going to want at least one or two visible for things like help/support, or you would kill this page altogether from the theme layer.)
New groups always appear in the admin directory (could have this but this kills flexibility; why not have a checkbox there and just default it to true all the time?)
Group creator chooses whether her group appears in directory. Checkbox defaults to *in directory*. (Sounds good; this is the current behaviour)
Group creator chooses whether her group appears in directory. Checkbox defaults to *not in directory*. (Hm, maybe. Could come in useful if a site wants private groups on the whole and only a couple public ones)

What about something like this?

- All groups default to show in the directory, and not visible on registration form.
- If the current user has 'administer organic groups' privilege, they see checkboxes to change these settings if they want, which default to enabled and disabled, repsectively. Otherwise, they don't have the option and will just see the rest of the form.

This way, we use an existing, positively-named permission to control this, and let the default behaviour stand.

This is exactly what I need. I want users to select only one of the official groups that my site requires during the registration process.

I am using drupal 4.6.6 and I get the checkbox while registration which I have preconfigured. But the problem is it still doesn't make my new user part of the group that he selects while registration. It adds og_register etc in user table but this user doesn't get added to og_uid table ?

Is this by design or I need to add the code where by I insert this new user to og_uid table subcribing him to the group that he selected while registration ?

Also if I am using Drupal 4.6.6 do I need this patch ? I can not seem to download this patch it just shows me part of the file in my browser.

Thanks

Drupalite, up until maybe yesterday or two days ago, there was a bug in the 4.6 version that would not subscribe a user to a group on registration. That has since been fixed. Please download a fresh copy of the module from http://drupal.org/node/13446/release.

That is separate from this issue, which is deciding when and how to display the options for showing a group on a registration page and not showing it in the directory.

- the intent of 'new groups don't appear in the group directory' is that the admins control the directory. thats what i would use on groups.drupal. you make a good point about the 'groups' breadcrumb. i'm inclined to leave that as is and let some contrib module change it as needed. it could be changed via theme_breadcrumb() as well.
- the nice thing about 'new groups always appear' is that it removes one ui element from the node form. i think some admins want this.

i'm still favoring the approach that i've outlined. anyone with further comment? i'm a little sad that the admin/settings/og form is going to grow by 2 more prefs but it is OK.

Got it now. Yeah, that's a good approach. I think I missed the sentence:

"Like the Public checkbox, node admins should always see this checkbox."

...from your initial propsal. +1.

Thanks webchick. After this new patch it worked.

For my site I have say main 3 groups A,B and C. Every user is part of 1 and only 1 of these 3 groups.
So what ever this user does I want it to belong only in his/her group so user from group A can't see or do anything in group B and so on.

I don't want to show these groups anywhere in my site except for registration. Once the user becomes part of this group upon registration he/she should never see main groups A/B and C on any page later. I don't know where I have to make this change to get this effect.

I was wondering about how to go about making 'public' field (that appears when user creates content) correspond to the main group to which this user belongs. So that when he selects public field it will automatically get restricted to group to which he/she belongs and doesn't become public for all members from all groups A/B and C.

Thanks in advance for your help.

committed to HEAD/4.7 as per http://drupal.org/node/47497#comment-87555.

Thanks, Moshe! This change has been back-ported to the 4.6 version of OG.