Improve the "OG content" view

[olafgrabienski]

The "OG content" view is supposed to show all content of a group. During my OG tests, I've noticed two issues:

(1) Out of the box, a block to place the OG content view in a layout isn't available. There is a workaround: creating the missing block, but it's not so easy: In the block display you have to change Block settings > Contextual filter input (data sources for contextual filters) > OG membership: Group ID source to "From URL" and "URL position: 2" (the latter corresponds to the node ID in node/NID). So, having the "OG content" view as a block display (and with the correct settings) by default would facilitate the configuration of Organic Groups a lot.

(2) When you post a content item to multiple groups, the item appears multiple times in the "OG content" view of each group. To display it only once per group, you have to change the view's "Query settings" to "Distinct". Is this the right fix, or should the provided view be configured differently at another place?

[olafgrabienski]

As a start, can someone confirm the behavior with the current state of OG? I've noticed the issues a while ago.

(And btw, IIRC, the Block settings issue from (1) applies also to the "OG members" view.)

[schoenid]

I can confirm issue (2).

(2) When you post a content item to multiple groups, the item appears multiple times in the "OG content" view of each group.

But I don't use content on multiple groups for the moment. If required, I will check the "Distinct" option.

For issue (1) I've created my own view which works best for my needs with the following settings:

RELATIONSHIPS

OG membership: OG membership from Node

CONTEXTUAL FILTERS

(OG membership from node) OG membership: Group ID --> Content ID from URL

BLOCK SETTINGS

Contextual filter input: --> No Filter

FORMAT

Format: Unformatted list
Show: Fields

FIELDS

Content: Image
Content: Title

FILTER CRITERIA

Content: Published (Yes)
OG membership: Group_type (= Node)
Book: Depth (= 1) ***

*** required for books without childs. If multiple content types are used, the use of attachements is possible, to have different filter settings for incompatible content types.

[schoenid]

OG members view:

The contextual filter setting 'out of the box' was:

CONTEXTUAL FILTERS

(OG membership from user) OG membership: Group ID --> Hide view

So I've changed it to

(OG membership from user) OG membership: Group ID --> Content ID from URL

Then everything was fine.

[olafgrabienski]

Thanks for your feedback @schoenid ! Regarding (1), I can confirm your views configuration works as well, so in theory we have two approaches to fix that problem:

• Change the Block settings of the "OG content" view
  Block settings > Contextual filter input > OG membership, Group ID source: From URL / URL position: 2 ...
• Change the Contextual filter to provide the node ID as default value
  Contextual filters > (OG membership from node) OG membership: Group ID > When the filter value is NOT available > Provide default value: Content ID from URL

Looking at them, your (the second) approach looks more usual and more robust to me.

[olafgrabienski]

so in theory we have two approaches to fix that problem

Well, I've just noticed there is a third approach. I had a look at a D7 site with OG, where the Contextual filter is set up to use the default value Current OG group from context.

Note: this value is only available if the sub-module Organic groups context is enabled. That could explain, why the block to place the OG content view wasn't available on my site. At least, I hadn't enabled OG context on the test site.

Now I'm asking me, if there is a reasonable way to provide a working view by default. And if not, how we can help site architects with our quite specific knowledge (enable the sub-module and change the Contextual filter).

[schoenid]

Note: this value is only available if the sub-module Organic groups context is enabled. That could explain, why the block to place the OG content view wasn't available on my site. At least, I hadn't enabled OG context on the test site.

The same in my case.
I've noticed also, that there is an additional permission entry 'OG permission', to use in the "Access Field" on Views, if the sub-module Organic groups context is enabled, as example:

ACCESS

Access:[OG permission] | [edit group]

It's also interesting, if you have a look at the new "OG context" configuration admin/config/group/context:

• There seems to exist a possibility to have users as groups or group content. I guess, that we only have to add a specific field to users. If this works, we would have the possibility, to manage content directly by users or even users in groups!

[argiepiano]

Well, I've just noticed there is a third approach. I had a look at a D7 site with OG, where the Contextual filter is set up to use the default value Current OG group from context.

Yes, that's exactly one of the goals of OG groups context module. From the module description: "Get a group from a viewed page".

I think it would be helpful to document these "tricks" in the OG wiki. Would one of you be able to tackle that?

[argiepiano]

Now I'm asking me, if there is a reasonable way to provide a working view by default. And if not, how we can help site architects with our quite specific knowledge (enable the sub-module and change the Contextual filter).

One more thought: some of the Views provided by OG only have a Master display. I believe they are there as "starting point" for admins to create blocks and pages from them. So, having these tips and tricks in the wiki would really help site builders.

[argiepiano]

And one last comment:

There seems to exist a possibility to have users as groups or group content. I guess, that we only have to add a specific field to users

Yes, you can make ANY fieldable entity (comments, even taxonomies, and custom entities) into a OG group or OG group content by simply adding the appropriate OG field. This can be done at admin/config/group/fields

[stpaultim]

One more thought: some of the Views provided by OG only have a Master display. I believe they are there as "starting point" for admins to create blocks and pages from them. So, having these tips and tricks in the wiki would really help site builders.

I don't see the advantage of this. I can create a page view from a block just as easily as I can from a master view. For me, it would be better to start with something useful by default rather than starting with something that requires extra steps.

Is there an advantage to starting with a master view, that I'm not seeing?

[schoenid]

Is there an advantage to starting with a master view, that I'm not seeing?

The only reason, I can see, might be, that it was thought as templates for blocks or pages, where the site designer decides, which to create.
As I remember, Views was a module in Drupal 7, which by default was showing the master ... I'm not completely sure ... it's long time ago. However, I prefer the views setting "Always show the Master display" enabled. But for new Backdrop users, this could be a sticking point ... (It's not long ago, I was one myself. ;)

[olafgrabienski]

For me, it would be better to start with something useful by default rather than starting with something that requires extra steps.

@stpaultim I agree, also because in Backdrop it's likely that people want to use a block. (In D7, without Layouts, blocks were a different thing, and OG in D7 provided some Panels' content panes for different views.) I'd suggest to open a new issue, with the goal to check and improve the default display of all OG views.

[schoenid]

For me, it would be better to start with something useful by default rather than starting with something that requires extra steps.

That's what I was meaning too, if not, with:

But for new Backdrop users, this could be a sticking point ...