Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I am using Spaces with OpenAtrium in several Intranet-like scenarios. However, my repeated pattern is a group with a public face, public listings, some public news and documentation, and then a bunch of private stuff that should only be exposed to members.
The OG Controlled preset gets me as far as a moderated public group, but I need that privacy checkbox. I'm willing to pull this functionality back out, but I'm looking for warnings or tips about what that will entail.
I have also tried meddling with the node grants system, but that is black magic that I only want to pursue if the direct approach would be more difficult.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | public_content-739878.patch | 1.12 KB | daven |
| #16 | 739878.patch | 867 bytes | ericbroder |
| #5 | spaces_private_content.tar_.gz | 2.42 KB | Grayside |
Comments
Comment #1
that0n3guy commentedsub
Comment #2
Grayside commentedI believe I've gotten a workaround working for me. I may polish it up and post it somewhere.
Still not nearly as good as having OG Access working with Spaces, but spaces_og turns out to be a heavier nut to crack than the node grants system.
Comment #3
MichaelP commentedI'd certainly be interested and willing to lend a hand with the polish if need be!
Comment #4
that0n3guy commentedI would also be willing to help out... this is something I've been looking for for a while in Open Atrium.
Comment #5
Grayside commentedCode attached. Read the README.
For an easier-to-access explanation of where this code is coming from, check out the page I tossed up.
Comment #6
mikemccaffreySilly question, but is there any reason that Spaces is still disabling the standard og audience checkbox?
It made sense when there was a public/private configuration for all feature content in a space, but since that is apparently no longer being supported, why not just return node-level access control back over to og?
Thanks any clarification!
Comment #7
Grayside commentedMy understanding: The main reason why that toggle was disabled did not relate to the public/private feature system, but to the preset for a public/private group.
It is a usability improvement which unfortunately cuts a major piece of functionality out of groups.
Comment #8
izmeez commentedsubscribing
Comment #9
mikemccaffreyDoesn't og already support public and private groups? Perhaps the reason for the reimplementation is that og didn't store the value in a variable that could be overridden by spaces.
Still doesn't seem like there is a reason to only ensure nodes are private if the group is private, and otherwise let the standard og checkbox decide if individual nodes should be private in public groups.
Comment #10
Grayside commentedIt is purely for usability purposes. It can be confusing for users who don't need fine-grained node access to have the option in front of them. I think it would be preferable to patch OG to have this as an option.
Instead, spaces_og overtakes the whole thing, and it's complex enough that I've opted to learn the node access system instead of figuring out how to "fix" Spaces.
Comment #11
jmiccolis commentedHi everybody,
I'm going to set this to won't fix. We're not going to support mixed privacy in og spaces. When we did have this functionality it was a world of confusion, mis-configuration, and just plain broken node access grants. We'll, or course, continue to support configuration at the preset level, but not toggling individual nodes in a public group to be private.
To be clear, Grayside is correct that this is a usability decision and not limited by any technical considerations. But it's a decision that I'm pretty happy with.
Comment #12
Grayside commentedIn that case, I'd like to chat with you about a separate contrib module or feature. I have code to take another pass on first.
This may be confusing, but it's essential functionality for my purposes. Well, this, or an especially crazy, feeds-based contraption. Occam's Razor is biased toward this.
Comment #13
mikemccaffreyJeff
Thanks a lot for the clarification. It makes a lot of sense that you would want to simplify the system, as node access grants and privacy settings can get very complicated very quickly.
However, I do worry that this issue might harm the chances of more widespread adoption of features and spaces. It is one thing to not support some use case in your module, but when you are reaching into another module and taking away functionality that people are already depending on, it might ruffle some feathers.
It just seems like something to think about while you guys are working on the module architecture over the long term.
One more related question, is the option to make different features within a space public/private now gone for good as well?
Thanks!
Mike
Comment #14
Grayside commentedOkay, I have a module that solves this. It's a bit strange, in that it basically conditionally changes how OG Access is behaving. On the plus side, it is abstracted with the concept of access policies, which allow arbitrary definition of what makes a node public vs. private.
I need to clear this module through my employers copyright review before I can post it anywhere, but it is *a* solution, and it is forthcoming. Hopefully within a few weeks.
Now, despite being mostly proud (and a little scared) of that code (and hoping to share it soon) I still think that closing off functionality in the name of UX is overreaching in this case. I think this concept should be viewed as a Feature Request. Spaces OG should have the ability to establish the UI it wants, but it should be somewhat straightforward to get around this as a site administrator.
Comment #15
Grayside commentedChanged the approach of the code to override the OG Privacy field instead of overriding the OG Access records. And published it: OG Privacy.
Comment #16
ericbroder commentedIt seems that Open Atrium / Spaces gets rid of the public checkbox feature from Organic Groups access control / configuration (OG Access). This Spaces module patch is an attempt to check for that public setting on a node before denying access. If you are trying to reinstate the public checkbox OG Access features, then this patch might be helpful.
Comment #17
daven commentedI'm attaching a patch for the latest d6 version (6.x-3.x branch). This patch is a bit of a different approach than Eric's as it makes changes in the space_og plugin instead but the logic is pretty much the same and still depends on the public checkbox. I hope this is helpful for anyone trying to do the same thing.
Big thanks to Owen for helping with this.