Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I've enabled the OG Content Access module and my features are default. All the node types now have a group_content_access field. So far so good.
However, the field never shows up in the interface.
According to this page it should be fairly simple.
Can anyone shed a light on this? Am I missing something?
FWIW: I've tried it on a vanilla commons 3.2 too.
Comment | File | Size | Author |
---|---|---|---|
#17 | Screenshot_6_13_13_4_40_PM.png | 11.69 KB | ezra-g |
#1 | Screen Shot 2013-06-12 at 3.44.10 PM.png | 56 KB | jpontani |
Comments
Comment #1
jpontani CreditAttribution: jpontani commentedI just tried it on a clean 3.2 install, and can't reproduce. It shows up fine in the UI when I added the field to Posts.
Comment #2
jpontani CreditAttribution: jpontani commentedWorks fine in 3.2, but in -dev, I am able to reproduce.
Comment #3
jpontani CreditAttribution: jpontani commentedSo for some reason the group_content_access field has the '#access' attribute set to FALSE, hence why it's being hidden.
I tested this with a quick hook_form_alter with the following:
The field now shows up properly. Still looking into the underlying cause as to the disallowed access to that field.
Comment #4
jpontani CreditAttribution: jpontani commentedSo in commons_groups, we're apparently forcing FALSE on the group_content_access field, specifically:
Going to have a chat and will figure out why we're hardcoding this to hide this field and OG_ACCESS_FIELD.
Comment #5
ezra-g CreditAttribution: ezra-g commentedCommons provides an alternate UI for group privacy settings, as implemented in #1961302: Streamline group privacy settings fieldset and show in the screenshots there.
As a result, the default OG documentation doesn't apply to group privacy settings.
Let's add this to the Commons documentation.
Comment #6
ezra-g CreditAttribution: ezra-g commentedAlso, see commons_groups_node_presave() for where we set some of these values behind the scenes based on the simplified UI.
Comment #7
BarisW CreditAttribution: BarisW commentedWhoa.. So does that mean that is not possible anymore to create private nodes in public groups and vice-versa?
That would mean I have to form_alter everything back in, as the current site (I'm migrating into commons 3) uses that a lot...
Comment #8
RobKoberg CreditAttribution: RobKoberg commentedI did a search for field_og_access_default_value before posting https://drupal.org/node/2019057 but did not find this thread (so I am putting it on the page now :) ).
OK, so the answer on how to get a node to have private content can be done in one three ways:
a) set the group to "Joining requires an invitation. The group and content is hidden from non-members. " (edited)
b) set the field_og_access_default_value to TRUE for the group content type
c) edit the group content type instance as an administrator or someone with permissions that are similar to admin's with regard to content editing.
I don't think this last one will work unless "Joining requires admin approval" is checked which means the checkbox on the page will be ignored regardless, so I guess this is not really a way to do. Perhaps there should be an initial check at the top of commons_groups_node_presave() to see if $wrapper->{OG_CONTENT_ACCESS_FIELD} is already set to TRUE (i.e. by an admin or similarly permissioned user)
Comment #9
RobKoberg CreditAttribution: RobKoberg commentedSorry, item C is totally incorrect. disregard it.
Comment #10
RobKoberg CreditAttribution: RobKoberg commentedI have just talked to project managers about this content privacy change to the way groups works and was asked to ask if we can get the ability to set content visibility back. This is for a large educational app from Pearson that will most likely be hosted on Acquia Enterprise.
Our use case is for Teacher > Student groups where the content is private. Some of those students will be under 13 and we won't be storing emails for them (COPPA), so they won't get emailed updates (I know, don't get me started). We have a group unique identifier set at the group level. Students use that at registration time or later in a group finder to find the group and ask to be members. We don't want the teacher to have to invite students to each group they create.
Is there any chance of not hiding field_og_access_default_value and allowing any type of group to have private content? I understand what you are trying to do, but it won't work for us. I will either need to drop commons or try to maintain my own version of commons_groups (don't know if that will even work). I have reset to active in the hopes that it will be revisited soon.
Comment #11
BarisW CreditAttribution: BarisW commentedJust to share how I 'fixed' it:
Plus the code below to add the privacy field to the BW Quick Post form:
Comment #12
ezra-g CreditAttribution: ezra-g commentedI don't follow how that's related to group privacy settings. Commons Groups in Dev also allows people to request membership to private groups which prevents admins from having to invite people to join private groups.
We definitely want to keep Commons flexible and able to meet a variety of use cases so I'd like to better understand your needs here.
If that's an important feature, we could certainly consider supporting that as an option or addition to the current UI - I encourage you to submit a feature request for it.
Comment #13
ezra-g CreditAttribution: ezra-g commentedComment #14
RobKoberg CreditAttribution: RobKoberg commentedBut that is not the commons access field. I fear there will be problems if commons uses one way and we use another.
Btw, doing the form alter for the commons access field has no affect because it is handled completely different than regular form submission.
Comment #15
ezra-g CreditAttribution: ezra-g commentedLooks like 12-14 were cross-posts. Setting back to "needs more info."
Comment #16
RobKoberg CreditAttribution: RobKoberg commented#15 ezra-g yes, my #14 was for BarisW #11.
Regarding #12, I don't see an example of a group with private content in the commons clean install (and choosing to populate with content).
Is it not correct that you have to set the Privacy settings to "Joining requires an invitation" which I assume means what it says. When I create a a group with that selection, as a different user, I can't even access the group page.
Or if that is all wrong, how do you setup a group with private content, but users can still see the group page and request membership?
Comment #17
ezra-g CreditAttribution: ezra-g commented1) Make sure OG Access module is enabled.
2) When submitting a new group (with the latest Commons_Groups dev version), make sure the Privacy settings fieldset matches this screenshot:
Does that resolve the issue for you?
Comment #18
RobKoberg CreditAttribution: RobKoberg commentedWill give it a try. Since I am using a different theme, that toggle is not happening for me.
Ideally that check box is not related to the one radio button or at least it relates to both anyone can join as well as administrator must approve.
I can see the argument for it not applying for private groups and it makes the UI better not to have that as an option globally available on the form. But the other two could use content privacy. We are trying to have the teachers do as little group admin work as possible, and thought it would be easier for them to remove people they don't want rather than have to approve people. A teacher may have thousands of students.
Comment #19
ceepeebee CreditAttribution: ceepeebee commentedReturning to the original issue:
"Group Content Access field is not displayed and thus cannot be used"
As stated above (see this page), the group content access field could be used to make specific content public even if the group is set to private (and vice versa)
Use case:
Most of a group's activity should be private, e.g. private posts, private wiki, private events etc.
But there are, for exapmle, some events non-group-members should be informed about, as well.
You need a private group (e.g. "Joining requires an invitation.") so that the group and its content is hidden from non-group members in general.
If you want to be able to set the group content visibility to public for specific content, e.g. one special event, you need to be able to access OG_CONTENT_ACCESS_FIELD, don't you?
@#14:I don't see that. Could you please explain your concerns?
As I understand #4 and #5 #1964282: Streamline group privacy settings fieldset had this option removed.
Here is the corresponding Feature Request to have it back again.
Comment #20
TuWebO CreditAttribution: TuWebO commented@jpontani from #4, did you figure out why it is hardcoded that way?
That leads to another problem if we want to show that field on node views. I've open a feature request #2207597: PATCH - Allow Group Visibility field to be visible on node view when og_access is activated for that. Maybe it is useful for someone.
Comment #21
isellakuria CreditAttribution: isellakuria commentedIs there a way to have the Group Content Access field displayed?
The provided patch does not work for me.