Support for private group homepages

I'd like to propose an alternate method for solving this problem: groups within groups. Right now, if I allow make a node a group home page node, I cannot add it to another group. While I'm sure there are good reasons for this, I think it prevents a logical way of creating hierarchical groups.

For the sake of example, let's use the problem I am working on right now. I want to create a ticket tracking and project managment system. Let's say I have CCK nodes for Organizations, Projects, Tasks, and Time Logs (the basic builidng blocks of my design).

Ideally, I'd like to make organizations, projects and tasks all be organic groups. That way, I can associate collateral materials with each one (eg. images for a theming task, blogs for a project, etc). Also, it is critical that I nest these items: an organization has projects, projects have tasks, etc.

To do this, we need to allow groups to be placed within groups.

This has the added advantage that if I create a Company X group and add Employee 1 ... 3 to it, I can create a project XYZ that only they can see - provided I do not make the node public.

Instead of hacking on the group listing page until it breaks in a 100 different pieces, why don't we look at embracing the node_access table more fully.

Attached is a patch that allows groups to be associated with parent groups. This was largely accomplished by just turning off the "safety" checks around group types. Group types can still be disassociated from the audience selection process, and og will preform just as it has previously.

There are some edge conditions that need further review and testing, esp regarding listing and subscription options.

Eg:
- what if the site requires one to post a group into another group (audience required) but there aren't any groups yet! ouch.
- what happens when someone asks for a group to be listed in the sites directory, but people can't see it because it was placed in a group (right now, I think this patch exhibits correct behavior - the group is not listed in the sites directory for people who do not have access to the parent group). i think this is more of a documentation, smart default issue

Apply and be merry. ;-)

-Mark

private groups is a separate issue from group hierarchy. also, group hierarchy implies for many people that content and or membership flows up or flows down through the hierarchy. it isn't simply allowing the group => group relation.

My patch doesn't say anything about hierarchical groups. It does, however, make it possible to place one group within another group, effectively making a group private. Hierarchical groups might be nice, but this patch does not address that need.

While there are probably several different ways to implement private groups, I would advocate for a solution that uses the node_access system. Since OG doesn't play nice with other node_access implementations (not the fault of OG, but of the NA system) the only practical way to do this is to include group node types in groups.

The downside to this solution is some added complexity and behavior change. Specifically the options "include in groups directory" and "include in registration form" become ambiguous. If a group is private, it really can't appear in the group directory for users not in the parent group. A private group should never appear in the registration form, because anonymous users are not part of the parent group.

As I mention earlier, I think the solution to these ambiguities is not different behavior on the part of OG but better options/UI.

Moshe: what are your criteria for including this patch? I assume #1 is convincing you that it is a good idea... ;-)

-M

i'm already agreeable to private groups. og will get a huge commit this week. see http://drupal.org/node/71420. lets revisit this issue once that lands.

trunk is in a good state now so feel free to reopen this discussion.

if we are just trying for more private (i.e. invisible to non subscribers) groups and not hierarchical content+membership, then i think groups within groups is too complex. i would rather just instruct the arbitrator to not write a grant for the group node. lets solve this for 5.0 and then backport something for 4.7 if possible.

I'm very interested in this feature too.

As for the 4.7 maintainer I'm bit weary about backporting this feature to 4.7. Seems like it is more 5.0 quality -- especially since it's dealing with the node access table and we know that has changed considerably in 5.0.

However, we'll see when the final patch lands just how complex the solution was and then we can debate whether 4.7 should have this or not :-)

Till then, I'm interested in progress on this issue and should be able to provide some more solid feedback soon.

i think #3 from the original post is quite doable. i'll get to it one of these days, if you guys don't beat me to it.

I like option #3 as well, and it perfectly resolves the issue I'm facing right now.

I'm very interested in this feature. I'm considering whether there should be an onus on other module developers to take notice of the "listed in directory" setting for groups, but ideally private groups needs resolving within this module so as not to cause work for other developers.

Is anyone working on this issue right now?

This issue is on making groups private; maybe the better solution for this task is to create a simple checkbox "Make this group private", that make the created group only visible to the group subscribers (only the author on creation).

Create a group within group seems more complex, even if it partially solves the same problem.

Starting from the patch from mfredrickson, this patch implements the possibility to create groups within groups and from that, the possibility to make it private to all user subscribed to that group.

The main idea is to treat a group as a post in a group, so a newly created post is only visible to the author until other users are added to the group.
As posts in a group, the "node-group" will be visible in all other groups associated to it or public if the public checkbox is set.

If a group type is selected in the "Omitted content types" setting, it will behave as in the current version of og, so it will be always listed.

As a "node-group" is automatically associated with itself, it is also listed in it's own og_ghp view.
There is some tweaking to do in the filters section of the view to make the current node not be listed in the group home page.

This patch allows to:

• Work with og in its standard behaviour, simply selecting the group type in the "omitted types list".
• Create private groups in a way that is completely transparent for the user. A group is created with its audience set by default to the group itself, and so it is private to the subscribed users, as long as it's not set as public.
• Create groups with audience. The group acts as a post in a group, so it can be associated with any group subscribed by the author.

I skimmed the patch and the ideas look solid. I'll commmit it once it is ready.

Lets add the issues mentioned by torne and then we all need to test this thoroughly with new and existing sites, and with different preference combinations. This is major surgery, and merits major QA before commit. I am very busy, so I rely on others to help out. You all are off to a great start.

Maybe this one only happens in HEAD for the timing being and backported to 5 once it's solidified? At least to help facilitate testing...

Fixes:

• Now users can't subscribe to a group they don't have permission to access if they know its node ID, by just hitting the subscribe callback URL directly
• Now og details block behaves as its own group.
• Fixed the ghp_view argument handler function to make current group not be listed in the group home page.
• Made the audience behaviour consistent between groups and posts: now a post that is not set as public and has no audience, is made private to the node author. Posts are no longer ignored by og if no "audience" and no "public" cheboxes are selected: if the user unchecks the public checkbox and doesn't select any group, then the post is made privete and so only the author can access it.

i only read through your post and noticed "now a post that is not set as public and has no audience, is made private to the node author". we actually want to change that. see http://drupal.org/node/107289

Looking at http://drupal.org/node/107289, I have updated the patch to avoid storing in og_ancestry table nodes that doesn't belong to any group; I make use of the node_access table instead.

However I left the default behaviuor to set groups and posts as private as long as 'public' isn't checked.
If we need public by default we should reverse the logic and use 'Private' instead of 'Public' (as said on the other issue).

I will wait further feedback before going on.

i haven't looked closely yet, but accessing node_access table directly is no good ... about to commit the "don't deny ..." patch so we have a better foundation to review from. if possible, please reroll this patch after that one lands.

Do we really want groups with audience or do we only want a new 'Private' checkbox that makes groups accessible only by the groups members (only the author/manager on group creation)?

I would like to know your opinions before going on.

@Luca - I assume your question is about UI on the group node form. Yes, I think a single *Public* checkbox is preferable over some sort of Audience checkboxes thing.

This patch allows private groups as proposed in the original post:

• Adds a flag to mark groups as private to make it visible only by its members
• If the 'private' flag is not set, groups are always set as public
• Adds a setting in admin/og/og to define the default behaviour (always public, always private, choosed by group creator)
• Adds a column in 'og' table to store private status

We can go on with this patch for private groups and start to arguing on groups within groups as a separate issue.

Has anyone tested the #29?

subscribing

subscribing

Does anyone have feedback on this patch?

subscribing and thanks for all the work here! you all are awesome.

Hey Guys,

I applied the latest patch for 5.x on a couple of different versions of og 5.x but could not get it to display posts privately.

The old 4.7 patch works in 4.7.

jim

I have updated og (at v 1.298.2.50) and re-applied the patch at #29. Everything seems working as expected.
Let me know if there is other work to do in order to make this patch "ready to be committed".

@ #35, can you point me the old 4.7 patch? thanks!

Hey Luca,

Thanks for the hard work. It worked great on a couple of fresh installs of 5.x.

Kind regards,

Jim

subscribing - where was this 6 months ago? love your work guys.

I have created a private group in og-5.x-2.2 by using the following settings:

• Core OG settings:
• Access control: Organic groups access control is currently enabled.
• Private Group settings:
• Subscription requests: invite only - subscriptions must be created by an administrator.
• [cleared] registration form
• [cleared] list in groups directory

This group doesn't show up anywhere, unless you are a member, and posts to this group also, not even in the Recent Posts view (tracker); as long as the Group Audience Public box is cleared for each node posted to this group.

This last point is the thing, If the core "OG Node authoring form" settings could become configurable at the group level rather than globally then I could stop accidental public postings (forgetting to clear the Public list box).

You see, generally I want to most groups activity to be visible to all - an open community experience, with the exception of this one group which needs to be private.

Is it possible to have the global Node authoring setting "visibility of posts" to be changed from the global value "Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Public." to a individual Group setting of "Visible only within the targeted groups" for a Private group.

This would then make the Audience bit disappear, or at very least I need the Group Audience Public box to be cleared by default.

Would this be a feature useful to others?

-Dave

What I just posted now I see has already be logged here "public/ private default should be on a per-group basis" http://drupal.org/node/43940

subscribe

subscribe
#29 patch applied. Not fully tested but seems to work Ok. Thanks.

i read through the patch in #29 and it looks good. alas, it doesn't apply cleanly anymore. sorry i delayed so much.

could someone please reroll this so it applies cleanly to HEAD/DRUPAL-5. those are identical still.

i went ahead and fixed the conflicts from the last patch and tweaked a small amount. new patch attached. i read through the code and all looks good. i did not test yet. i'm still uneasy though ...

- we are now allowing public posts from within private groups. how is that understandable to mere mortals?
- this patch allows you to check the register checkbox and check private. that makes no sense. we need some js to prevent that confusion on the form.
- this patch allows you to 'list in directory' and be private. that works, but the private group will only show to those who already are subscribers. i don't think thats what people will expect.

i'd like some input on these issues. if they aren't show stoppers, how do we mitigate the confusion?

- we are now allowing public posts from within private groups. how is that understandable to mere mortals?

It could be useful to let users post public contents within "private" groups to let them show posts which could be interesting or related to other groups.
It's the same as to post a content in two different groups: one setted as private and one as public.

- this patch allows you to check the register checkbox and check private. that makes no sense. we need some js to prevent that confusion on the form.

We can make the "registration form" insensitive if the "private" checkbox is set (just as for public checkbox in posts if no groups are checked).

- this patch allows you to 'list in directory' and be private. that works, but the private group will only show to those who already are subscribers. i don't think thats what people will expect.

This could be useful to make "private" groups be showed in the list for subbed users, just for listing purpose. It makes no sense to let everyone see the private group in the list, otherwise we can't call it "private".
The other way, is another bit of js to make it insensitive while "private" checkbox is set.

My question is really about user experience - ae we complicating this module beyond a critical point with this private groups option. There certainly is a rationale for all of our choices, but the sum could make a rather unpleasant meal. Any other opinions on the merit of private groups and how to handle these admin issues in a pleasant way for the user?

Hm. Yes, this definitely is sticky. I would just say "remove the capacity to cross-post to private groups" but I can see a couple different use cases:

1. "Global" announcements that need to go be cross-posted to all groups. (Notice: Site maintenance on Friday from 2-4 PM)
2. "Global internal" announcements that need to go to all internal groups. (Notice: Inter-departmental meeting on Monday at 9am.)

Either of these would be extremely tedious to do if you had to create the same announcement multiple times.

However, we need to be very careful about a situation like we could have with the SoC 2007 Mentors group and the SoC 2007 Public group on g.d.o. Let's say someone cross-posts an announcement to both the SoC 2007 public group and the private SoC 2007 mentors group, "Mid-term evaluations due next week." If I read the post in the SoC Mentors group, and don't happen to notice that it's both a) public and b) also cross-posted to the public group, I might make a comment like, "Yes, I'm a little worried about Student X, because they haven't been responding to emails, etc." Obviously, that's not something we want to show up on the public group... :\

About the only thing I can think of at the moment is a big, blinking red JS confirm box that notifies people that they've selected both private and public groups, and the consequences of that action. And make sure that that's displayed on the node itself so when people comment they're aware.

That said, I would like to voice my opinion that this is a very desirable feature. Envision a MySpace-like clone where you want the internal development team and moderation team to have their own group to sort out their issues. You wouldn't want existence of these groups public knowledge, even if all posts within were private and they did have to guess "node/124" to get to it.

I also would like to see this feature implemented, and would find it core to the website that I'm currently building. I'm not much of a coder, but would be happy to help test for bugs.

on a side note: could someone direct me to help apply the patch. I've applied patches manually to programs such as phpbb, but this is a different system. Is there a program that would make things easier?

Moshe,
I have been following this thread closely. I am new to drupal and my php skills are basic. I would love to test the patch and provide feedback, but need some guidance on how to install it. I am starting a community website that needs private groups.

I have also discovered that even if you make everything about the group private (not listed in the directory, by invitation only), if an outsider can guess the URL, he can pull up the group homepage. Does this patch fix that?
Thank you, Chris.

webchick, the issue you mention exists but it happens regardless of whether a group is private or not

However, we need to be very careful about a situation like we could have with the SoC 2007 Mentors group and the SoC 2007 Public group on g.d.o. Let's say someone cross-posts an announcement to both the SoC 2007 public group and the private SoC 2007 mentors group, "Mid-term evaluations due next week." If I read the post in the SoC Mentors group, and don't happen to notice that it's both a) public and b) also cross-posted to the public group, I might make a comment like, "Yes, I'm a little worried about Student X, because they haven't been responding to emails, etc." Obviously, that's not something we want to show up on the public group... :\

What this patch does is to let the administrators hide the soc private group, so that users doesn't even know it exist, it has nothing to do with private "posts" inside that group, in fact you would have the same problem if the group was public, but its posts restricted to the group members.

So this should be addressed in a separate issue because it's an issue that already exists regardless of this patch.

Subscribing

Tested the patch in #45; it applies cleanly against HEAD and appears to work as advertised, both for users excluded and users included in the private groups. Note that as you would expect, the "Administer Nodes" access permission will override the privacy setting and allow you to see/enter all groups. That might be a good item to include in release notes or other documentation.

this patch allows you to 'list in directory' and be private. that works, but the private group will only show to those who already are subscribers.

I like this behavior - I would expect private groups to be visible in the groups list to those who are subscribed to those groups.

Catching up on my e-mail and just found the question from Moshe on the UI: "how can a Private group can contain Public posts?".

Webchick suggests there is a use case for announcements to be cross posted. If this is the case, how about restricting cross-posting to private groups to those with the "administer organic groups" or "administer nodes" permission? It seems reasonable to prevent normal users from cross-posting, and would mitigate some of the UI concerns.

This is indeed a very useful feature. Much needed.

However: I think what webchick points out in #48 is very important, and I would say for that reason that it is best not permit posting publicly in a private group.

(I did not completely understand #52, but even if it is irrelevant for this patch, that issue is important, and I dont think this patch should assume anything else than that the source to such a confusion will be removed).

DanielTheViking, the issue metioned by webchick isn't introduced by this patch, so i think it should be addressed separately, even if this patch doesn't get committed.

Think about a group which anybody can see that it exist, but posts are restricted to the subscribers. To join you must be invited. This group isn't private, but yet it is affected by the public/private posts issue.

This patch simply makes it possible to hide the group from everybody, except its subscribers, it doesn't touch the posts.

subscribing

#57/Egon:
Yes, the main point here is to get the possibility to hide selected groups from view, which is important.

It seems to me that it is still relevant to mention that the possibility of posting publicly in private groups should be avoided. (simply too "dangerous") I am just voicing my concern over that by chiming in with others that warn against the consequences of that possibility. As long as it is not encouraged, "introduced" or "supported" by this patch, I am fine.

I just cannot seem to grasp what you refer to as "existing":
Is that already possible? I admit I havent wrapped my brain totally around this issue or even all aspects of this thread/patch, but as far as my impression goes, I am not aware of that it is possible as of now to post publicly in private groups. Correct me if I am wrong or have misunderstood your point.

Anyway, is there a feature request filed on this (separate) issue already, either to remove that possibility or to actually get it? Please post a link if there is such a feature request somewhere, as I would then like to chime in there instead.

Looking forward to this important patch. :-)

webchick and pwolanin make a convincing argument to deny crossposting into private groups except by admins (administer nodes permission). egon is right that this patch doesn't introduce this issue but it will confuse unspsuecting admins even more. anyway, i think denying cross posting is wise here.

yet we haven't really addressed the troublesome 'Public' checkbox. do we also force that to disabled for private groups except for non admins? i think so.

in both cases, a non-admin who attempts one of these actions would receive a validation error upon submission. he would then need to remove to remove all other groups or remove the private group from the audience field. he also would also have to uncheck the Public checkbox. Then his post would be accepted. Sound OK?

we need some javascript on the group form to handle these UI conditons from my earlier post:
- this patch allows you to check the register checkbox and check private. that makes no sense. we need some js to prevent that confusion on the form.
- this patch allows you to 'list in directory' and be private. that works, but the private group will only show to those who already are subscribers. i think we should disable "list in directory" if private is enabled. some contrib module can override us if needed.

yes, this is headache inducing.

In looking at issues related to UI, would it be better to have the option be disabled, or to have the option not appear at all?

Personally, whenever it's possible to simplify the UI by removing options/text from the screen, I think it's a Good Thing (tm) -- and I think this UI would benefit --

At the risk of inducing more headaches:

Scenario 1: a user is posting into a private group from *within* that group
The UI would only give one option -- post into that group

Scenario 2: a user wants to post into a private group, but they navigate to node/add/nodetype from, for example, the contact page (ie, outside a private group)
The UI presents three options -- the public checkbox, a section listing public groups, and a section listing private groups. If a user selects a private group as the audience, then the other options get grayed out/disabled.

This also, of course, raises the issue of whether cross-posting should be allowed at all for private groups, as the membership of two private groups could be different -- if a private group is meant to be a fully private, self contained area for work by a selected group of people, then cross posting between private groups probably shouldn't be allowed at all.

'Public' checkbox. do we also force that to disabled for private groups except for non admins? i think so.

I think it should not be visible except for admins.

If a user selects a private group as the audience, then the other options get grayed out/disabled.

That sounds like a nice and logical/non-confusing UI.

The readme/documentation and on the online help page there can be a list of the options that are available only to admins.

I think there is a bit of confusion, so I made a diagram to explain better how I see the whole thing.

Legend:

• O: Open group. Anybody can freely subscribe to this group to view its posts and add new posts.
• R: Restricted group. Only invited users can view its posts and add new posts.
• P: Private group. Only subscribed users can view its posts and add new posts.

Critical situations:

• Case 1: User-1 posts node-1 in groups P, O. User-2 submits comment-1 to node-1 with sensitive information. User-3 and user-4 will see the comment. Not good.
• Case 2: User-2 posts node-2 in groups R, O. User-3 submits comment-2 to node-2 with sensitive information. User-4 will see the comment. Not good.

Observations:

• A: If you take P out of the equation. Case 2 is still there. As of today case 2 occurs with organic groups enabled.
• B: The issue of case 1 and 2 occurs only when posting comments, because the node author knows where he posts his nodes (audience checkboxes).

Conclusions:

• A: This is an issue not related with Private groups.
• B: Limiting crossposting when Private groups are involved, only solves case 1. Case 2 is still there.
• C: One possible global solution, is to entirely disable crossposting, but we don't want this.
• D: Another possible solution, is to show a notice in the comment form when appropriate.

In my opinion, we should commit the Private groups patch, and start arguing in another issue to decide the most suitable solution for the problem in posting comments.

Can this patch (and issue) be updated to apply to og-5.x-3.1 rather then og-5.x-1.0? It would make more sense to test and review it then. I am not capable to do it or I would.

Otherwise I think -1 for cross posting, absolutely. Although I think it could be useful for announcements by admin but in such case wouldn't you like to email instead to bring attention and in any case I think it should be a separate module instead of bloating og "core".

In general I think it's good to think "private is private and public is public, you can't have both at the same time - it doesn't make sense". I you want an exception, create a nnew module for it or hack, that's my $0.02

Perhaps we should postpone the cross-posting and put it in its own feature request for later, if that can help save time and energy, in order to get this patch finalized and committed quicker?

Then we can continue the debate in the other issue queue whether or not it is possible to avoid confusing UI/logic with such an option.

I agree to that, but part of the problem now is that the patch doesn't apply on any of the newer og versions.

Hi everyone!

Here is the updated patch against og 5.x-3.1 release. There were no surprises updating the patch, but it would be good for someone to double check my implementation in og_node_access_records(), which has totally changed in og 3.1. I think I am doing it correctly, and I have tested it and verified that the group homepage is appearing and not appearing as it should (either not at all, only if I'm a group member, or for everyone depending on permissions and the settings of the private checkbox).

This patch might even apply to 3.x-dev / HEAD, if not I will revise it so that it does and post that too.

Reading everyone's comments, I agree totally and suggest we use this up to date patch to get this committed if it looks OK... then address the remaining discussion in an appropriate new issue thread.

D.

many thanks to everyone working in this issue ... i am not so comfortable with this patch yet. needs javascript/ui help as i mentioned earlier. further, i am not so sure about "commit now, discuss later" approach. later may not ever come.

Agreed later may never come, so let's identify the scope of the remaining problems and address them. It seems everyone agreed in the prior discussion that the cross posting was a separate issue then the patch was out of date.. so now the patch is up to date anyway.

Moving forward, I will try and address the JS issues you spelled out in #60:

we need some javascript on the group form to handle these UI conditons from my earlier post:
- this patch allows you to check the register checkbox and check private. that makes no sense. we need some js to prevent that confusion on the form.
- this patch allows you to 'list in directory' and be private. that works, but the private group will only show to those who already are subscribers. i think we should disable "list in directory" if private is enabled. some contrib module can override us if needed.

It would be really helpful if someone could point me in the direction of a good example of working form validation JS in Drupal so that I have something to copy from. I can't think offhand of any core or contrib parts using JS that would be similar, but given one I can get the required functionality in here.

Other than the cross posting thing, and those two quoted issues above, let's identify anything else that needs figuring/addressing to get this feature implemented.

I would like to propose that we try and get this working with the existing patch state and the above fixes, then address some of the following in a future version and with more discussion:

- The Public checkbox for non-group nodes vs. the Private group checkbox on a group, confusing?

- What happens when you change private checkbox on a group with posts already in it? Should it cascade permisisons

to all posts within that group so they are no longer public? And in that case what if the private checkbox is un-checked, should all posts be made public again? The answer to both of these questions is "probably not", I think. But is that intuitive enough? Can we solve the problem with documentation/help explaining what will happen?

- Should we replace all mention of "private group" with "private group homepage", thereby sidestepping the cascading permissions thing. If people understand we are talking about making the group node itself (the "group homepage" to most average users) private, maybe they won't expect the cascade effect.

I think this patch greatly extends the usefulness of og now, without necessarily coming to final perfect solutions for the above three. While I agree we have to discuss this or later may never happen, I think we should also try and get this important functionality in there, with a stable base version.

Obviously if the consensus is that we don't have that yet with this patch, then I guess we don't.... but it is certainly working well for me and deployed to my users and has for several versions.

I'll see what I can come up with for that javascript, if you can point me at an example of form JS that would be super. And if anyone else has comments on missing functionality for a base verson, let's figure out what else needs to go in. Finally if anyone can see anything that is going to paint us into a corner and prevent us from improving things more in a future version, then we need to identify those too.

D.

og.js has some javascript already which is helpful here. check that out first. the ideas carry over to group node form.

Ref. #68 - ""commit now, discuss later""

If "later never comes", that could be an indication that the postponed issues are less important, and then at least the important part is finished and committed.

I applied and tested the patch in #67 with version 5.x-3.1 and found no bugs in my testing. I tried making various private/public posts and groups, which all worked fine for me. Although my tests were fairly extensive, I wouldn't say they were a complete testing.

changing the title back

subscribing

Subscribing to this issue.

I patched my og.module with the latest patch available and i must say it works very well. It was exactly what i was looking for. In fact the only little thing that might be corrected is when the private module (http://drupal.org/project/private) is also installed: this private checkbox might tend to confusion since this one is not working with group node content. (When i began searching for the present patch i was trying to understand why the private module was not working for group node content - but i dont really have an answer since i stoped looking for it because the present patch resolved my problem). So when present, the private checkbox from the private module should not be displayed for group content editing. Otherwise, it's perfect! But i am aware that it might be an issue for the private module more then this patch... maybe the private module should give the option to decide which content types to make private.

thanks for your work!

just a follow up to mention that what i was talking about already have been patched:
http://drupal.org/node/119216

here too:
http://drupal.org/node/124439

but i cant make both working :(

Hi Pht3k, glad to hear it worked for you, thanks for the testing/feedback.

I am just swamped right now but plan to revisit this issue in a few weeks and get the javascript in there so it's closer to RTBC.

meanwhile if anyone using this patch has problems (other than the private checkbox issues already identified) please follow up with them... some more testing would definitely good. I myself am rolling private groups and og2list out to a really large drupal site in the next couple of weeks, that should make for some good testing too :)

D.

I tried the patch a week or two ago. Unfortunately, while it does make a group private it doesn't look private when editing a private group. The private checkbox is unchecked. Has anyone seen this?

@christefano - I've not seen this behavior, but it was fairly tricky getting this part of the code to work right. It sounds like something is going wrong around where it chooses what default for the checkbox. Something could also be wrong with the database. Did you run update.php after installing the patch? You will need to have done so to create the og.private column in the database.

Here is the relevant checkbox code (line ~1205, the whole thing begins at line ~1176). Note these line numbers are from og 3.1 patched with the _0 private groups patch from #67 on this node)

  case OG_PRIVATE_OPTION_CHOOSE_FALSE :
      $form['og_private'] = array (
        '#type' => 'checkbox',
        '#title' => t('private group'), 
        '#default_value' => $node->nid ? $node->og_private : $default, 
        '#description' => t('Should this group be visible only by its subscribers?'));
        break;

could you a watchdog statement before that switch statement and see what is in the $node variable? It would also be helpful to print the $visibility variable. If you add the following watchdog statement before the switch ($visibility) { (line 1189 for me) then cause the problem, it will hopefully show what is going on. Then post back what comes out of the watchdog here.

  watchdog('ogprivate',"Visibility is: $visibility.  Node contains: [" . print_r($node,TRUE) . "]"); 

Also have a look in your DB in the "og" table and make sure that the private field is set to 1 for the group. You will need to look it up by the nid of the group (in the watchdog output or hover over the edit tab of the group homepage and you'll see it).

As I'm unable to replicate the problem on any of my sites I'll need this info to see what's going wrong.

Thanks... can anyone else verify this problem, or help with more testing of private groups?

PS - I can provide a patch against current -dev if anyone wants to test with that, just reply here.

While testing this private groups patch on a new site I ran into a new problem. The new site had a large number of public groups already and the global visibility settings for og were set to be always public (these settings are in admin/og/og under Node Authoring Form, Visibility of Posts).

When I created private groups, users posting content into those groups from the group block were creating public posts. If a user had "administer organic groups" permissions they were shown a checkbox for "Public" under audience, which defaulted to true.

The proper behaviour for private groups is posts to never ever default to Public. So I added some smarts to the patch to accomplish that. It now checks to see if the post is specifically into a group (via the ?gids[]=XXXX on the query string or via the hidden form vars). If any of the groups given (there is usually just one) is private, then the setting is overridden to OG_VISIBLE_CHOOSE_PRIVATE, which shows the Public checkbox and defaults it to un-checked.

Finally, if the global og visibility settings are already forcing private posts (OG_VISIBLE_GROUP_ONLY) then the setting is left alone, there is no need to present the Public checkbox as the site amin has chosen for all group posts to be private.

Note that $gids has already been initialized at the top of og_form_add_og_audience()... Here is the new code:

  // If the post is to a private group, and $vis is not OG_VISIBLE_GROUPONLY, 
  // override to OG_VISIBLE_CHOOSE_PRIVATE so that posts in private groups will never default to public.
  if (count($gids) && $vis > OG_VISIBLE_GROUPONLY) {  
    foreach ($gids as $gid) {
      $group_node = new stdClass();
      $group_node->nid = $gid;
      og_load_group($group_node);
       if ($group_node->og_private) {
         $vis = OG_VISIBLE_CHOOSE_PRIVATE;
        break;
      }
    }
  } 

It is definitely a bit confusing how these are two types of settings - one global and then one group by group which can override the global in most cases. I am open to suggestions of a better way to organize all this... but meanwhile it continues to work for me and provide an essential function.

As I said in last comment, I can provide a patch for the current og HEAD if anyone requests it. Otherwise this patch still needs more work on its javascript to make it to RTBC.

Thanks for following up, damien. I did run the update.php script and private groups were private. It was the JavaScript that had problems (as you just said in your last post). I'll revisit this when I have time. Thanks for the updated patch.

Hi Guys,
Thank you for your awesome work here.

And thanks in particular to damien_vancouver.

I've been able to easily patch og-5.x-3.1 with the patch in #82.

However, I still have posts, supposed to be exclusively viewable in a private group, as publically available (E.g. from the latest posts block etc.).

The functionality looks fine though, because even in TABLE og everything seems to be ok and 'privat' is actually getting set to 1 etc.
But I still haven't been able to work out where this value is actually being called..

I'd really need posts withing a so called 'private' group only available to subscribers of that particular group.

Any ideas?

Response would be very much appreciated ..

1... Is the Private Group patch still valid for 5.x-4.0 ?

2... Also, Is there any word on getting this patch put into the OG module instead of patching?

3... Seems like a few OG experts have posted here so I would like to ask anyone reading this to have a read of my forum post and tell me if I am headed down the right road (Which includes the usage of the OG module and the Private Group patch)... http://drupal.org/node/185039

Thanks!

tracking

subscribe, seems not to apply to "5.x-4.0".

I've updated the private groups patch for og 4.0.

Please comment back here if you run into any problems, it tested OK for me.

INSTALL INSTRUCTIONS (for new installs)
- install og 5.x-4.0
- apply the attached patch to the og folder. It will update og.module and og.install
- run the update.php page for your site and run og update 20.

UPGRADE INSTRUCTIONS (existing og private groups users from og 3.1 patch)
to upgrade you have to run the updates in the right order. That is because your Drupal site will already think it's run og update 19, which is a new update. You have to run the new update 19, then install the patch, then skip update 20.
- upgrade your og module files to 4.0
- apply the private groups patch attached to this comment.
- run Update.php and og will show an update 20 to run. This is the private group field that you added in your old version, so it will cause an error when you run it. You are missing the real Update 19, so change the og dropdown so it shows "19" and hit Update.
-Update 19 should run correctly and Update 20 should fail saying something like:
Failed: ALTER TABLE {og} ADD private int(1) NOT NULL default 0.

Note: this patch still needs javascript to get it closer to being committed. I'm going to try and do that now as well, but since I might not get it right the first time, I'm going to submit that in a different comment.

The attached file og_5.x-4.0_private_groups_patch_0.patch is the right one to download for people wanting to use it with 4.0.

@Damien, thanks for the patch. It doesn't seem to work for me.
I checked the 'private group', set the group to 'invited only' and unchecked the 'list in groups'.
However, when non-subscribed user enter the group node they can still see it exists.
I've check access rights, seems ok.

Am I missing something for testing the patch?

@Amitaibu, it sounds like you have done everything correctly.

Is this a brand new install, or did this site already exist? I ask because there are known problems with the node_access table and og... for a variety of reasons you can get a row in there with nid=0 that is realm og_all granting a view. If this row is in node_access (it gets in there for broken historical reasons) then your access control will not work for private groups (or anything else og related).. even though it seems that it will work.

See the closed issue http://drupal.org/node/159410 for mor information on this.

Check your node_access table and make sure there isn't a row in there with nid=0, realm = 'og_all'.

What appears to cause this is a rebuild of the node access table where you have data orphaned from old users, or at least that is what caused it for me. In any case, running the delete query suggested in comment #6 on that issue, "delete from node_access where nid = 0" should remove any of those rows and maybe cause things to start working.

If it doesn't, then please provide some more info about your environment. Try it on a new drupal test site without any existing data, verify if the private groups part is working, that will help identify whether it's a problem with something in your DB like the node_access prob or the patch not working correctly.

I have deployed and tested it on several sites, and have received feedback that this one worked from a couple other people. Which is not to say that it's correct, there may well be a bug, but I'll need help reproducing it. Please try some of this stuff first, and see if it fixes it, and if not we'll go from there.

good luck!

Ack...I tried the 4.0 patch and had the same exact problem as Amitaibu :( I tried all the solutions at http://drupal.org/node/159410 and they didn't help (there weren't any nid=0 rows, and I tried rebuilding permissions). A test user who isn't a subscriber of a group is able to see the posts of the group that was marked as private. I'm running Drupal 5.3 with a pretty clean install of OG4.0 (meaning the very few changes I made were tiny UI changes that I know wouldn't conflict with this patch). In the og table, the private group does have private set to "1". I followed all the directions step by step and double checked to make sure the patched lines were properly placed. Any suggestions or other tables I should check? Amitaibu, have you made any progress?

Thanks

subscribing.

@tj2653,

>A test user who isn't a subscriber of a group is able to see the posts of the group that was marked as private.

That is the normal behavior, the private groups patch only affects the group home page and sets defaults.

So with it installed, a group marked private will not let unsubscribed/anon users see its homepage.

Also any new posts created in that private group will default to having the "Public" checkbox UN-checked under "Groups" in the edit form. That means that any new posts from when the group was set private will need to have "public" explicitly checked for people to be able to see them.

BUT, any EXISTING nodes will still retain whatever permissions they had before the private groups patch was added.

Also if users specifically choose to make the post Public as well, then anon / non-group users will be able to see it.

So to confirm, if you log out then go to your group's home page, e.g. http://www.example.com/my_group , do you see an access denied or see the group home page? If the patch is working you should see the access denied - ditto if you go toi the group homepage from a user not in the group.

If you want to change a bunch of existing content to be private after enabling the private groups patch, you have to edit the content one node at a time or do some sort of mass update of perms via the database.

Please confirm whether the group home page is accessible.. if so then it definitely shouldn't be, I'll do some testing on a clean new site and see if I can replicate... but it is working properly for me. For example: http://beta.postcarbon.org/og2list_test is a private group, its homepage should refuse to display to the general public.

one more comment - this does raise the question of whether the private groups patch SHOULD force any content in a group marked private to be private, regardless of what invidual permissions are on the node.

I'd like to see this patch get finished (javascript), everyone agree it's working at protecting the group home page and also setting the default public box unchecked when creating new nodes. Then we could look at extending its functionality with some more controls in the admin/og/og page...

ie. have another option which is "Force Private Group" or something like that, where anything in a group marked private is immediately off limits, and node permissions would still be saved normally but overridden in hook_nodeapi() for load, view etc.

This would not only allow the functionality some people want, but would give an easy way to handle existing old content, without having to do some sort of cascading permissions update - node permisisons would be preserved as the originally were and merely overridden when the force private groups checkbox is set - which could just be the setting of this patch's private field to 2 instead of 1.

But... one thing at a time, let's get the basic functionality working for everyone. Please test those group homepages both of you and let me know.

Hi Damien,

Thanks for the response. To further clarify, the unsubscribed member DOES see the private group homepage. That user is a normal user, and not an admin, etc. Yes, please let me know if you can replicate using 5.3 or something similar. I'll try some more testing on my end too.

On the topic of private content inside private groups, that would be a very nice "to do", but like you said, one thing at a time :)

Regards,
Cary

Hi Damien,
I've created a new installation (5.3), and still non-subscribed user can see the group.
I've attached a link to my SQL, and the patched OG module (just in case).

Admin - amitai/ 12345
user - demo/ 12345

Here's my info:

Drupal	5.3
Configuration file	Protected
Cron maintenance tasks	Last run 15 min 19 sec ago
You can run cron manually.
Database schema	Up to date
File system	Writable (public download method)
GD library	bundled (2.0.34 compatible)
MySQL database	5.0.37
Organic groups modules	Organic groups works best when job_queue.module.module is enabled. See the Integration section of the README file.
PHP	5.2.2
Unicode library	PHP Mbstring Extension
Web server	Apache/2.2.4 (Win32) PHP/5.2.2

Hope this info helps.

OK, I found and fixed (I think) the problem.

When i was copy and pasting stuff from the patch file for og 3.1, I put the grants statement in the wrong place by accident.

So the problem was that new groups being added were getting an og_public grant when they shouldn't. Even though the group correctly gpt private = 1 in their og row, they had the public grant in node_access still, making any new groups public even when private is checked.

The attached version should work properly.

To fix any groups that the old version did not make private, you need to delete the rows in node_acces for the group where realm = 'og_public'.

e.g. if your group's nids are 1234, 1235, and 1236 use: DELETE FROM node_access WHERE realm = 'og_public' and nid IN (1234, 1235, 1236)

sorry about that! and thanks for the help testing! Let me know how this one works.

Thanks Damien, but I'm still having the same problem :( I applied the new patch to the version of my files before I tried the patch the first time, and with my pre-patched DB. I ran update.php and ran through the rebuilding permissions routines again as a precaution. However, a non-member of the group can still see the homepage of the group I marked as private.

Okay, I might be getting somewhere in solving this problem (or maybe not). I rolled back my database and 2 file changes, and I went into the OG admin and Enabled Access control (pre-patching). Then I patched with the new patch again, updated the DB, and if I make the group private, the unsubscribed member can't see the private group in the group listings at all (eventhough I have "list in directory" checked) - unexpected behavior, but closer to the result I want. Only my one public group shows in the list. When I go into the admin and make the private group public again, it shows back up in the list. So...maybe if I can have it show up in the directory listing when it's private and the "list in directory" option is checked, it might work?

Does this make any sense? I thought that access control option was only to allow an admin to have rights in all groups, etc....and really shouldn't affect any of this - which is why I never had it enabled.

Hi,

I ran the latest version of the patch from #97 (had never ran any of the previous versions), i ran update.php (update#20 - "alter of ADD private int(1) NOT NULL default 0"), i noticed that og access control had switched from enabled to disabled so i enabled it again. i deleted the rows in node_access for the group where realm = 'og_public' amd i updated my group content type and updated all of my group nodes.
I still experience the behavior that damien mentions - when a test user who is not registered with any of the groups is able to enter all of the groups that are marked private (also they are marked to list in the directory).

OK, to troubleshoot you two further I need to see the node_access rows for your groups to see what's going on, also any node access rows where nid=0. Please post back the output from:
SELECT * FROM node_access WHERE nid IN (0, 123, 456, 789) <-- replace 123,456,789 with a list of your group nids

The best way to do this so you can paste it into a comment is in the command line MySQL client... e.g.: mysql -u myusername -p drupaldbname
will log you into database "drupaldbname" with user "myusername" and prompt you for a password.

I tested everything again on a clean CVS install and it does appear to all work for me. Here is a complete test of everything with the exact steps I followed. I do believe you guys that it's not working for you, but hopefully this will help you see what is different somewhere.

It's almost certainly issues surrounding access control and node_access. Any of those pesky nid=0 gid=0 rows in access control will make it so everyone can see everything.

@tj2653, it looks from #99 like it is working right for you. A private group wont' show up in list in groups directory - in fact one of the leftover tasks for this patch is to get javascript on the form so you can't check both those at once (see #45 and #60 from moshe in this thread).
But anyway what happens when it's not showing up in the groups directoy and you try and visit the group homepage? see my test plan below on what you should be expecting and testing.

@graceahora, to me it sounds like you have some other access control issue. Let's see a dump of your node_access rows for both nid=0 and the nids of your groups. Make sure you have at least one private and one public in your output, make a public test group if you need to.
node_access rows are likely what's wrong in your case... Also check and make sure you have the private field properly set in the "og" table for your group...

Here's the test plan I followed from start to finish:

Preperation: Drupal 5.3, og 4.0, views 1.6, configuration...
-checked out DRUPAL-5 from CVS
-checked out og 4.0 from CVS
-checked out views 1.6 from CVS
-applied private groups patch from #97
-enabled clean urls
-enabled views, views_rss, and organic groups
(note: since i was pre-patched i don't need to run update #20)
-made a group content type, with comments disabled (admin/content/types)
- configured og in admin/og/og:
-- under Access Control, pressed "Enable" to turn on access control
-- under Group Home Page, set the group home page node type to be "group"
-- Under Node Authoring Form, Visibility of Posts, choose "Visibility chosen by author/editor using a checkbox oin the posting form. Checkbox defaults to public".
-- saved and double checked og config
- create a new test group - create content -> group
- checked "private"
- checked "list in directory"

- looked in node_access table, only one row is there for my private group:

+-----+-----+---------------+------------+--------------+--------------+
| nid | gid | realm         | grant_view | grant_update | grant_delete |
+-----+-----+---------------+------------+--------------+--------------+
|   1 |   1 | og_subscriber |          1 |            1 |            1 | 
+-----+-----+---------------+------------+--------------+--------------+

Test 1: Anonymnous perms
- Now, log out and try and visit the group homepage...
I get an access denied visiting http://localdrupal/node/1

- Look in the groups directory:
I see no groups listed.
(the patch needs javascript to stop private groups and list in directory being clicked at the same time, or we need to make it so it is possible to list private groups in that directory by further patching og)

Test 2: Logged in users that don't belong in the right group
- Log back in as admin
- turn on the group blocks in admin/build/blocks
-- just visit that admin/build/blocks and the group blocks should be set to show up on the left sidebar by default, but that will not be in the database yet. Press Submit to save the settings and the group blocks will now appear on the left.
- set content creation permissions so users can create group content:
-- visit access control at admin/user/access and check "create group content", "create page content", and "create story content" for authenticated users role and then save permissions.
- Now go to admin/user/add and create a test regular user: testuser1
- Create two more test groups with create content -> group:
Testgroup2 is public, and testgroup3 is another private gruop. list in direcotry does not matter.
afterwards, node_access should look like this:

+-----+-----+---------------+------------+--------------+--------------+
| nid | gid | realm         | grant_view | grant_update | grant_delete |
+-----+-----+---------------+------------+--------------+--------------+
|   1 |   1 | og_subscriber |          1 |            1 |            1 | (testgroup1 - private)
|   2 |   2 | og_subscriber |          1 |            1 |            1 | (testgroup2)
|   2 |   0 | og_public     |          1 |            0 |            0 | (testgroup2)
|   3 |   3 | og_subscriber |          1 |            1 |            1 | (testgroup3 - private)
+-----+-----+---------------+------------+--------------+--------------+

nid=2 is my public group. Note how it has the extra public grant.

- Visit tesgroup1 by clicking on it in the group directory as your admin account
- click on "1 Subscriber" in the groups block on the left sidebar
- press "Add Subscribers" and add testuser1 to the group

Now: testuser1 belongs to testgroup1, and should be able to see testgroup2,
but should not be able to see testgroup3.
- Log out as administrator
- Log in as testuser1
- immediately in mine I can see testgroups 1 and 2 in the defualt /node page, but not 3.
- verify that testgroups 1 and 2 are the only ones that show in the groups directory
- try and visit testgroup3 by going to its link. (in my case: http://localdrupal/node/3)
- You should get access denied

TEST 3: Verify default overrides for audience checkboxes in private group
- As testuser1, go to the groups directory then testgroup1
- On the left, in the testgroup1 group block, select "Create Story"
- Put in the required title field, and scroll down to "Groups" wher the audience checkboxes are
- Note that "public" defaults to un-checked, even though it's set as the default in admin/og/og.
This is the private group override working to help prevent accidental public posts in private groups.
- save the post
- verify that the post is not public by logging out and revisiting the page (on my site, /node/5)
- you should receive an access denied

TEST 4: verify default behaviour for audience checkbox in a public group
- select tesgroup2 and choose to subscribe to it as testuser1
- under "testgroup2" block on the left, choose "Create Story"
- Note that the Public checkbox should be checked here (the default).
- post and test perms if you want but this is the default behaviour so won't have changed.

... all 4 of these tests should behave as I've documented here. Then, if old groups have the correct node_access permissions and the right value for private in {og}, then they should also work as documented here.

Anyway, let's take a look at those node_access rows and see what's going on!

Hi Damien,

That's good that I was seeing the right thing for a little bit. I say "a little bit" because after I rebuilt permissions, something entirely new occurred. When a once private group gets set back to public, the unsubscribed user can enter the group and see the group homepage, but gets a:

"No public posts in this group. Consider subscribing to this group in order to view its posts."

message when there are indeed posts in the group. When set back to private, the user gets the "Access Denied - You are not authorized to access this page." message if they try to go to the group's homepage URL (which I believe is the correct functionality).

I definitely support any efforts to "making it so it is possible to list private groups in that directory by further patching og". That is a feature I really need, because for what I'm running, I think group managers will want to be able to make a private group, but at least let others have the option of seeing it in the groups list so interest in the private group is still there.

Thanks,
Cary

@torne - pardon my ignorance, but how can I set all of its content to be private? I'm new to OG and have only been using Drupal for 3 weeks now :)

@torne - ahh, thanks for the explanation. I guess what I'm really hoping for is the patch to configure post visibility by group then :)

AFAIK, right now the only way via Drupal is to open and re-save each node with the "Public" checkbox un-checked in the Audience.

Permissions on individual posts (nodes) are seperate from permissions on the group itself (a special type of node).
As for it working a little bit for you, that's what you are seeing - the private group patch only does two things:

1. make the group node itself ("the group") invisible or visible, both if you go there and also if you go to the groups list
2. make it so it's hard to accidentally post a public node if you are posting it into a private group. You have to explicitly turn on the "Public" checkbox.

The functionality you are looking for is more of a privacy override for private groups, that handles all content within that group. It could be done, but so far no one has worked on it. I see that as a logical next step to attack after the functionality here.

Ideally this patch would be named "Support for private group homepages" not "Support for private groups", and then there'd maybe less confusion as to what it does and doesn't do.

In regard to the overriding privacy on group content... I've thought about this some since first taking over this patch, and where things get confusing trying to design how that would work is when posts belong to multiple groups.

This is a lot easier with a concrete example, so let's suppose I am in group: private_group_A and not in group: private_group_B.

A user in private group B makes a page/story in that group, and under the Groups audience checkboxes they select both private_group_B (selected by default for them) and private_group_A.

So now this post is in two groups, both are private: A and B, but I am only in group A.

As a user in group A, should I get permission to see that post? I AM in group A.
But should a post in private group B be shown to anyone who is NOT in group B?
Really it could be called either way, depending on what behaviour you are designing for.
Trying to plan for it by having the appropriate node_access records in place makes it very difficult to switch which behaviour you want (say in admin/og/og, were this functionality to exist).

Therefore I think one way to approach it might be to do it in hook_nodeapi when $op=load or view or whatever. Any node being loaded with groups could have a quick check to see if any of those groups are marked private. If so, then it could behave differently depending on how it's configured:
- either: Allow me to see the private post because I am in at least one of its private groups (group A)
OR: Deny me to see the private post because I am NOT in at least one of its private groups (group B)

Which behaviour happens could be configurable with an og setting in the systems table. It's really a business decision of how you want to handle that scenario. Best of all, the administrator can change their mind about this... it's a complex human interface issue and likely to change depending on how the users feel this week and which way the wind is blowing, etc. It could be even turned off completely in disgust, thus reverting to the built in behaviour of going strictly by what is in node_access for individual nodes.

One other approach (or perhaps they are complementary) is the ability for the group administrator to force all posts in the group to be public or not. However this does NOT handle my scenario of group A and group B well at all. You could get group adminsitrators from both groups fighting it out on node permissions. (ie group B keeps making them private, which is then noticed by group A admin who makes them all public again and so on).

Finally, there is the global setting for visibility that torne mentioned in his last comment. Does this just set the audience checkbox defaults or will it actually manage permissions on-the-fly for existing content? anyone?

Anyway, from my perpsective I'd like to make sure that the patch was behaving as it was designed to do... it does sound like it's working right now, just not doing everything that you'd hoped or expected.

I can see the argument for list in groups directory and private at the same time.. for a simple example of how that could be useful in the groups list:

Groups:
* Public Content
* Premium Content (paid members only)

Or something like that... it may be advantageous as a form of advertising to list groups that you can't get access to without paying, rather than to have them secret. Maybe instead of a private group checkbox there should be a group privacy setting with options Public Group, Private Group, and Secret Group. However that sounds a lot easier said than done, knowing a bit about how node access permissions work in Drupal. Making it show up some of the time and not let you load its content and treating those as two different types of load.... my brain hurts already!

If/when I can get this private group HOMEPAGE patch RTBC, I'd be willing to help collaborate on fancier privacy options. But for now it's mainly a matter of learning how to use the audiences and having good defaults set before users start making a bunch of public content you want private...

anyway... despite its awkwardness to understand, this patch really DOES work well when you have it set up right (from the beginning). As long as you realize that all it's doing is those 2 things, protecting the group homepages and setting defaults. That could be a lot clearer, especially if you are new to Drupal! ;) Before the patch is ever going to make it RTBC it should be clear what is happening and why from the help on-screen .

@Damien - I really appreciate all the work you are doing on this patch. I intend to commit it one day (am pretty busy ATM). Thanks for persisting.

I retitled the issue as you suggest.

Yes, there are use cases for requiring membership in all the groups versus any of the groups. Currently membership in any group is sufficient. If folks want 'all', they should review this fine patch by agentrickard. I think this need could be more generally solved outside of og.

We cannot rely on nodeapi to restrict access to nodes. This has been discussed elsewhere several times. See http://drupal.org/node/143075

That visibility setting just sets the defaults on the node form. Similarly for those other node form settings. Thats a really important point that I have not made clear. Folks can drastically change how og works just with some simple form_alter calls. The backend respects whatever the form tells it. So if people want per group control on the Public checkbox, they just havce to wrote a form_alter() to set it and hide it as the group admin wants. Or as the node type dictates. My point is that the node form is easily altered, and the whole node save workflow doesn't attempt to enforce any rules. This is a good thing.

Another good example is that 'show in directory' checkbox. What I want to see in this patch is that we add some javascript which instantly unchecks and hides this checkbox if a group chooses Private. Anyone who wants to put private groups in the directory put in their own javascript to change this. In any case, the node_save() flow will honor whatever the form tells it.

damien,

thanks so much for helping me to figure this out.
my mysql ouput is at the bottom, but just a little info first:

Groups 166, 210,221 and 482 should be private. 268 is public.

i noticed now that when i go into group 210 and 221 i see a message at the top of the group homepage that says, "No public posts in this group. Consider subscribing to this group in order to view its posts." The homepage can be seen, but all the posts are hidden. That's great except that i really don't want non-subscribers to see the homepage because they can still add content without being registered with the group.

In groups 221, 268. I can still see the homepage and can see the posts that are set to private.

But now, also with the patch i have two checkboxes in the group node form: "Private" and "private group."
Should these both be checked?

the private field in the "og" table for your groups is set to 1.

i have no rows in my node_access table with nid=0

Below is the output of my node access rows:

 `node_access` VALUES (166, 1, 'example', 1, 0, 0);
 `node_access` VALUES (166, 116, 'example_author', 1, 1, 1);
 `node_access` VALUES (166, 166, 'og_subscriber', 1, 1, 1);
 `node_access` VALUES (210, 1, 'example', 1, 0, 0);
 `node_access` VALUES (210, 1, 'example_author', 1, 1, 1);
 `node_access` VALUES (210, 210, 'og_subscriber', 1, 1, 1);
 `node_access` VALUES (221, 1, 'example', 1, 0, 0);
 `node_access` VALUES (221, 1, 'example_author', 1, 1, 1);
 `node_access` VALUES (221, 221, 'og_subscriber', 1, 1, 1);
 `node_access` VALUES (268, 268, 'og_subscriber', 1, 1, 1);
 `node_access` VALUES (482, 1, 'example', 1, 0, 0);
 `node_access` VALUES (482, 116, 'example_author', 1, 1, 1);
 `node_access` VALUES (482, 482, 'og_subscriber', 1, 1, 1);

@graceahora,

It looks like your node_access rows are all wrong, for instance your group that should be public doesn't have the 'og_all' grant it needs to be public. See #101 for what you want your node_access rows for your group's nid to look like.

But, the double private checkboxes are a hint as to how it maybe got so confused... I think you have your og configured wrong. The "private group" checkbox should only show up for node content types that are marked as group homepages in admin/og/og... maybe you have selected all the ndoe types to be the group homepage?

Just create one content type in admin->content management->content types, call it "group" (or whatever you want), and then in admin/og/og under Group Home Page, Group Home Page Node Types make sure only "group" is selected (or whatever you called your group type).

anyway that should fix your double checkboxes then. You should only see the Private Group checkbox when you go create content -> group.

Then once that's fixed, for your node_access table and the wrong permissions on each of your groups you want private, I'd just rebuild it by hand in phpmyadmin at this point.

Back up your database first of course (!),

...and then go edit the node_access table for one of your groups so it looks like #101 (depending on whether you want the group public or private). For instance 268 needs the og_subscriber and also the og_all grant.

Once that's done test again.. fiddle as necessary until it is working properly for the group homepage. Remember og access perms wont' work right for it if the content type isn't configured right in admin/og/og (and the double private boxes are gone, so private group only shows up for create content -> group)

anyway that should sort you out I hope... otherwise I guess stage a fresh install get it working there for 1 or 2 groups and copy the node access rows that way... sooner or later it should work.

good luck!

Here is a version of the private groups homepage patch that will work for og 5.x-4.1 release!

@Moshe, I also added the javascript we need to get this moving towards RTBC. Here's a summary of the new changes outside the usual functionality from last version. I organized them by what form they appear on, as there are three forms now with javascript on them from og.js (I added the last two, maybe not the ideal way, see my questions at the bottom):

On the existing javascript for node authoring in og.js
- I cleaned up some stray tabs, you will see these at the top of the og.js changes, followed by the new code
- eclipse fixed a missing newline at the end of the file while making the patch

When authoring a new group, i.e. create content -> group:
- Added the javascript suggested by Moshe to prevent "Private Group" and "List in Group Directory" being both checked.
- Updated the description for each checkbox so it says the other will disable it
- In the case where the form is loaded and both options are set in the DB, do not change the values, and leave both checkboxes enabled.
... if the users fiddle with the checkboxes they will start en/disabling as expected
... this allows people to use hook_form_alter() to save conflicting values in the DB, and hopefully og will never do anything crazy to those values.
... if the user leaves them alone it will let them submit and save without wrecking the existing settings.

On the og settings form, admin/og/og:
- Group details -> Private Groups now plays nicely with Node Authoring Form -> Visibility of Posts. If you select groups to always be private, you cannot select posts to always be visible (visibile to the targetted group and other groups). If you select groups to be always public, you cannot have a node visibilty of targetted only in the current group. The converse is true, setting the visibility options will appropriately disable/enable the always private or always public group details setting.
- When the settings form is loaded, if conflicting values are set in the database then the private group setting is adjusted to a sensible default, allowing the group admin to choose and defaulting to private or public accordingly. This will elegantly handle existing data from existing groups with just the visibility set and older versions of this patch from before the javascript.
- More help was added to Group details -> Private Groups to better explain what it does - sets the perms on the home page and defaults on the node authoring form.
- Help as added to each setting's description to explain that it might be disabled due to the other.

still a few jQuery details though..
This one's a lot closer to RTBC :) But I still am confused on a couple of jQuery things that could be more elegant I think:

1. Right now the drupal_add_js() call to add og.js just attaches all the functions to every form. It would be nicer to cleverly detect which form was being presented, and only try attaching that part of javascript. There are now 3 forms with the javascript on them. jsQuery does not cause an error or complain doing it this way, so maybe it's not a big deal, but it should save a few cycles.

2. For the first two forms Drupal forms API I guess is adding the id="edit-og-whatever" ID attributes to the HTML. These don't appear in og2list.module but seem to get added at render time, which is great, it makes the jQuery syntax easy. But for some reason all the radio buttons appear without an id, forcing me to use the longer XPath syntax to identify the object. It would be nice to do it the simpler way... is there some way to make Drupal spit out the id attribute? Or is something wrong with the og admin menu code that is preventing this from happening?

Anyway neither of these affects the functionality, which seems to work pretty good in all my testing (if I do say so myself! ;) )

This is definitely a lot closer!! let me know what's next and I can keep working at it.

People trying out the patch with og 5.x-4.1, let me know if you have any problems. If you are unsure of how to test the patch is working, see comment #101 for the test procedure, which should still be correct for this version (there is just extra javascript as described here).

The "private group" checkbox should only show up for node content types that are marked as group homepages in admin/og/og... maybe you have selected all the ndoe types to be the group homepage?

No i have only the "group" node type selected as my group homepage. I think i was misunderstood. The "Private" and "private group" checkboxes only show up in my group nodes (for adding or editing).

I edited my node access table by hand and now the groups that are set to private are in fact private.
( I also notice that somehow my access enable button in admin/og/og had become un-enabled and i had to enable it again - i think that was messing me up).

I would also vote, though for putting in a feature to allow groups to appear in the group list but not be accessible to users unless they are subscribed.

I have cases where the group's information is not necessarily top secret but they are small groups collaborating on specific projects and may welcome new members, but want to be aware of who the new members are that are coming into the group - especially if they have the opportunity to post information.
Also, i have users who are not very internet savvy and find it most convenient to find their group by clicking on it in the list of groups.

For the most part at this point, it is most important for me to have all my groups listed in the directory. And if that is the case, then i should not be using the "private groups" checkbox. Correct?
And then i am better off just trying to make sure that all the nodes that are posted in the (more) private groups are set to "private." Correct?

Thanks so much for all your hard work.

Looking good after a quick code review. A few notes:

* OG_PRIVATE_OPTION_ should be OG_PRIVATE_GROUP_
* you cleaned many tabs but also introduced some of your own.
* we really ought to find some cleaner jquery selectors as you mentioned. help wanted.
* i'm not terribly keen on leaving "migration" code in og.js so that they get good defaults the first time they save the settings page. If this can be sensibly moved to update.php. i would prefer that
* og_form_add_og_audience() is terribly complicated already. I'll have a closer look at what we're doing there.

@graceahora,

For the most part at this point, it is most important for me to have all my groups listed in the directory. And if that is the case, then i should not be using the "private groups" checkbox. Correct?

I think that's right... even if you were to have "list in directory checked", the group wouldn't show up the directory for users that aren't in it, because they don't have the node_access grant to be able to see it - they won't pass the og_subscriber grant and there is no og_all grant.

You could test this theory though, maybe they will show up if that checkbox is checked. With the latest version of the patch javascript will prevent that, so test it by manually setting the "directory" value to 1 for a group that also has private=1 in the "og" table. Then log out and see if it shows up in the listing, it probably won't even though it's marked list in directory now.... because anonymous doesn't have the og_subscriber grant to even access the node for it to make it into the directory. This is a feature of how node_access works. :(

And then i am better off just trying to make sure that all the nodes that are posted in the (more) private groups are set to "private." Correct?

Yes, I would go into admin/og/og, under Node Authoring Form - Visibility of Posts and set it to be "Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Private.". However, then people posting into groups wanting public content must remember to check the public checkbox. Up to you which is the lesser job, policing private posts that should be public or editing private posts to make them public.

When using private groups you typically choose the other setting, "Visibility chosen by author/editor ... defaults to public", and then any private groups will override that default back to private again, leaving you with mostly public posts by default and private in your private groups.

It seems to me like you really do need all the private groups functionality, but also the directory listing ability. I'd personally attack getting the directory to do what you want and use private groups rather than not use private groups and have to hope everyone always chooses private etc or deal with the permissions not working globally.

If we could figure out a clever way around node_access hiding private groups, we could then maybe allow list in directory and private group at the same time, but not right now (unless your testing shows that putting the group private=1 makes it show up in the directory for people without a grant, but I don't think that's how it will work). My only clever idea was using hook_nodeapi() which will not do the job as revealed in #108 (http://drupal.org/node/143075). So that is coming, but not till Drupal 7 (http://drupal.org/node/122173). For the meantime we have to grin and bear it. I'm sure if you found a workaround hack for making the directory work, it would be valuable to others in that same situation. If you do find a workaround, please share it here!

@moshe,

* OG_PRIVATE_OPTION_ should be OG_PRIVATE_GROUP
* you cleaned many tabs but also introduced some of your own.

OK and oops!, I'll run the next one through emacs ;) Stupid eclipse opens the .js files in gedit, which then adds tabs (but has really lovely colour syntax highlighting for javascript)

* i'm not terribly keen on leaving "migration" code in og.js so that they get good defaults the first time they save the settings page. If this can be sensibly moved to update.php. i would prefer that

Yes that's a good idea. It would remove a few lines of the convoluted part of the javascript.

As detailed in #114 I am pretty sure that having list in groups directory makes no diference for a private group, so it wouldn't hurt to force the values to be correct in the DB if that's the case. There is an update 20 in the patch that can do it in SQL so I'll move it to there for the re-roll and simply add UPDATE {og} SET directory=0 WHERE private=1 AND directory <> 0 to the update sql.

I'll re-roll and resubmit shortly with those changes.

That update is not needed as noone should have a private=1 or a private column at all for that matter.

If you are someone looking for the og 4.1 private groups patch, the attached is the most current version, og_private_group_homepages_patch_5.x-4.1_1.patch. Use it over the one from #111.

@moshe,

That update is not needed as noone should have a private=1 or a private column at all for that matter.

Right you are... I keep thinking of it from my situation where I already have data in there ;)

OK, this one is considerably simplified as per your suggestions...

- general cleanup of the og.js changes. much shorter comments that are clearer. Order of the code reflects order of the form. Comments properly describe what is being affected by each block of code. Removed the extra stray tabs I introduced and further cleaned up some formatting to match the coding standards.

- removed compatibility check javascript from og setings form handler. The problem shouldn't occur as you described, and even if you somehow do have them in an incompatible state, some trial and error with the controls will eventually allow you to get them en/disabled as you need

- simplified if/then logic for the group home page node form. (It still won't disable both checkboxes at once when loading the form, just in case.... Otherwise there is no way in the UI to get one of them enabled so you can fix it, unlike the radio buttons for private/node visibility (where some clicking will rescue you).

- fixed some of the constant and form var naming. The "option" everywhere came in the original version of this patch. Nothing else in og seems to be labelled "option" so I renamed it to be consistent:
... OG_PRIVATE_GROUP_OPTION * is not just OG_PRIVATE_GROUPS_*
... og_private_option is now renamed og_private_groups for the setting value from admin/og/settings
... "og_private" is for the group node's privacy setting, as before (this is unchanged)

While doing the terminology changes I was looking again at the wording of the Node Authoring Form - Visibility fields on og admin settings:

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.

Perhaps we could reduce confusion further by having this read something like below instead:

Group Content is always Private and is visible only within the targeted groups.
Group Content is always Public and is 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.

just an idea... at the very least the first two lines are missing a period to make them consistent... but adding the P words here might help people understand better with the addition of the private group options. The updated descriptions in the patch will need updating again if we change those, but they could then be shorter.

anyway let me know what next.

YHS,

D.

@damien,
I've ran the patch against 5.x-4.1 but I'm getting errors:

$ patch -p0 < og_private_group_homepages_patch_5.x-4.1_1.patch
patching file og.module
Hunk #1 succeeded at 19 with fuzz 2 (offset 6 lines).
Hunk #2 FAILED at 1119.
Hunk #3 FAILED at 1176.
Hunk #4 FAILED at 1276.
Hunk #5 succeeded at 1662 with fuzz 2 (offset 55 lines).
Hunk #6 FAILED at 2201.
Hunk #7 FAILED at 2553.
Hunk #8 FAILED at 2586.
Hunk #9 FAILED at 2609.
7 out of 9 hunks FAILED -- saving rejects to file og.module.rej
patching file og.js
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 18.
2 out of 2 hunks FAILED -- saving rejects to file og.js.rej
patching file og.install
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file og.install.rej

If we could figure out a clever way around node_access hiding private groups, we could then maybe allow list in directory and private group at the same time, but not right now (unless your testing shows that putting the group private=1 makes it show up in the directory for people without a grant, but I don't think that's how it will work). My only clever idea was using hook_nodeapi() which will not do the job as revealed in #108 (http://drupal.org/node/143075). So that is coming, but not till Drupal 7 (http://drupal.org/node/122173). For the meantime we have to grin and bear it. I'm sure if you found a workaround hack for making the directory work, it would be valuable to others in that same situation. If you do find a workaround, please share it here!

well i messed around with the settings and the database tables every which way i could think of to make a private group show in the group listing, but to no success.

Unfortunately, at the moment, i really need to have all the groups listed in the directory, so i'll have to go patchless unless something changes. It's not so bad. As long as the users don't make any of the group posts public, then non-group members see the following message when they enter the group,

"No public posts in this group. Consider subscribing to this group in order to view its posts."

And even if a group member makes a public post, all the private posts in the group still remain private.

Thanks again for all your hard work. I'll continue to follow the post and see where this patch goes...

@graceahora: thanks for confirming whether that checkbox even does anything, I guess we doi have to wait for D7 to solve that properly, then can revisit the idea of list in directory as well as private.

@amitaibu: Not sure why it didn't work for you, I just re-downloaded the og release tarball and patched: (since I was using CVS before):

[/tmp] ettin% tar xzvf og-5.x-4.1.tar.gz 
og/
   [...]
og/LICENSE.txt
[/tmp] ettin% cd og
[/tmp/og] ettin% patch -p0 < ../og_private_group_homepages_patch_5.x-4.1_1.patch 
patching file og.module
patching file og.js
patching file og.install

seemed to work OK. Anyway, I attached all 3 files, just rename them from .txt to the correct extensions and try that.

note that there must be a dupe file as drupal added an underscore to og.js's filename, remove the _ as well as the .txt so its filename is og.js!

Well, IMHO this thing is ready for prime time. I have been testing this out every way I can think of and it works great for at least my use case. I finally have true private groups and all the content is totally private away from non members of each group.

So this one has my vote for final inclusion into OG.

@Moshe - I think this version is ready for your final review. Just my 2 cents.

just to be clear are the 3 attachments above a replacement for the og module ? or do we add it to the current og version

@joninpo,

correct - the three files from #120 are the patched module files. You can either use the patch utility and apply the patch from #117, or manually replace the 3 files from #120.

Each one needs to be renamed -
og.js_.txt becomes og.js,
og.install.txt becomes og.install
and og.module.txt becomes og.module

then save them over top of the og 5.x-4.1 release files in your sites/all/modules/og folder or wherever og lives.

Finally, run update.php for your site - there will be a new og update #20 that you must run.

I cleared out a few bugs tonight and released 5.4.2. That will likely be the last release until 5.5.0 which should have this patch in it. I will thoroughly review this one next - I haven't forgotten. I expect it to land before New Year.

I extended this patch for a few edge cases and then committed. Great work, everyone. Special thanks to damien_vancouver for his persistence.

Please test the new release candidate and open new issues as needed. That release candidate is at http://drupal.org/node/205228. I'd love to get this into the official release quickly.

Tests OK for me!

http://beta.postcarbon.org/damientest <-- private group
http://beta.postcarbon.org/test_it_private <-- private post using default group privacy options on a new blog post.

thanks Moshe!

Hello everybody,

Happy New Year!

I downloaded and tested this new release, it's wonderful. I try to use it to create private workplaces on a marketplace application.

I have the following settings on the organic groups configuration:

• New groups don't appear in the groups directory. Administrators control the directory exclusively.
• New groups don't appear on the registration form. Administrators control the form exclusively.
• New group home pages and default audience are always private.

At the group creation I choosed closed subscription:

• closed - subscriptions are fully administered by an administrator.

However, the newly created group is visible to the anonymous user, if I try to acces it by the node URL (/node/node_id) the title and the mission statement content appears.

The group isn't visible in directories, it can't be accesed via /og, /og/my, /og/all, but it shows up through direct URL request - but only for the anonymous user, the authenticated users can't see it at all.

I have Drupal 5.3, group module reinstalled. I cleared everything before, groups, group content type, categories, taxonomy rights. I cleared the cache, and I rebuilt all permissions after the module install.

Has anybody noticed this behavior?

Thanks,
Michael

I cannot reproduce that bug. Please try with a clean install. If still a bug, please reopen a new issue.

I want to limit the search and give each group the results of its own group.
in og.module there is functionality to support that,
but it doesnt work.
can someone help me solve this problem?

Please don't reopen closed issues with unrelated support requests. Open a new one instead.