Differences between OG and group module, text for project page.

Group.module is still under development. The goal is similar to that of og: just provide a way to group your content into buckets and provide a layer of access control around that. The difference is that I'll do it using off the shelf modules, and less custom code.

Closed as the project has been taken over and will have a new release soon.

To clarify, without meaning to open an old thread (just didn't seem right to start a new one extending the same conversation), based on your description on the project page this is not what is inferred. OG groups content. You infer on the project page the opposite: that groups will now be entities which can group anything, namely, users (which OG really doesn't make a primary goal). This could group content OR just be a container for users.

What I mean by that is the description on the home page seems to make it very easy in this approach to group users and treat them as a single entity as opposed to a "bucket of content". I will use a more specific use case to illustrate. For our intentions specifically, OG has never really worked well with allowing companies to purchase products, via Commerce, through other users. Groups seems like an easy way to be able to have someone purchase a product, then have a customer service rep move them into a group, for say the salesman. That way you could break down total sales, what sales, what buyers, number per buyer, ect. by each salesman.

To sum: Is I wrong in the interpretation of the description that Groups will more easily allow you to more effectively group users in a more efficient "container" since it is based on entities or is this primarily attacking the same goals as OG?

A good way to look at a Group is indeed as a container which:

• can have any type of entity added to its contents
• can have fields attached to it
• can have members with roles and permissions for the content in it

For your use case, one way to do it would be:
Group: Salesmen
Admins: Customer service reps (CSRs)
Members: CSRs and salesmen
Content: Pages, news posts, etc. visible to CSRs and salesmen only

Group: Name of salesperson, subgroup of Salesmen
Admins: CSRs
Soft admin (limited rights): The salesperson
Members: The salesperson and their clients
Content: Content of interest to the salesperson's clients

An alpha release is coming soon™, I'll update the module page accordingly when it 'hits the shelves'.

That paints a much clearer picture of how the module works. Although it will only be an alpha release we are excited to see the module and the possible addition to our high volume complex e-commerce site using a similar use case as above, albeit not quite a simplified.

Can't wait to see it!

With og-7.2.x using an entity approach has the difference between groups and og changed or disappeared?

Organic Groups 2

• still hi-jacks or repurposes nodes
• only fieldable entities can be groups
• has an entity appoach

Group

• has its own entities to deal with group functionality
• can have any entity as children, even non-fieldable ones
• doesn't just have an entity approach, it's 100% based on entities

Footnote

Please read the Group module page thoroughly to get a general idea of what Group is.
I'll be glad to any any more questions you may have afterwards.

Edit: related topic #2096453: What's the difference between this project and GCC?

Please document the differences between the modules on the project page. (A short "Alternatives" section would be great for this, with a paragraph or so for Organic Groups.)

It would help users decide which module to use.

If you look through the project page's history, you'll notice we recently decided to remove that comparison.
See: https://www.drupal.org/node/711148/revisions/view/11104573/11192015

The reason it was removed is that Group came (really) late to the party for D7, but seems to be the go-to solution for D8. As everyone and their dog is/should be on D8 by now, it seemed pointless to keep the comparison so we removed it to avoid confusion.

That made sense when there was no work being done on OG in D8, but that confusion is coming back now that Organic Groups has a D8 alpha2 release, and is actively being developed currently.

That text should be brought back from the dead.

I suggested the same thing over there in #2591017-65: [og] Organic Groups.

Yes, it's exactly the commit referenced in comment #10 that could be reversed because it is useful information for people to see. That combined with what's in comment #8 says a lot. Having both on the project page may be very helpful. Beyond that is anything else needed for the project page? Possibly not.

Further discussion on the differences between the group and og module can continue in the other thread #2591017: [og] Organic Groups to avoid duplication.

With an RC for Group and alpha for OG there is noting to compare.
Feel free to set to active when an RC for OG arrives.

@kristiaanvandeneynde Hope this compromise is acceptable for you, if not, feel free to close again.

Please DON'T continue this discussion in #2591017: [og] Organic Groups. Stop abusing those issues!

Agreed. When both have stable releases, a comparison page should be made in the D.O documentation section. For now, just use Group for D8.

If you're still building complex new features or even new sites on D7, you've got bigger problems than having to google the differences between Group and OG 🙈. (They are floating around out there in blog posts, Drupalcon videos, etc.)

Just for reference comment #64 by @amitaibu in #2591017-64: [og] Organic Groups includes a useful link to https://www.gizra.com/content/og8-development-mindset/

I built one site using Group, for newer site(s) am switching to OG. The main reason is that the abstraction between content and group content in Group adds far too much effort for my rudimentary use cases. I suspect the majority of use cases don't need this extra abstraction, but it's good to know there's an option (Group) for projects that do need it.

I am just starting out with Group so perhaps not qualified to comment yet; but lots of experience with OG (D6/D7).

I have seen comments point out that a downside to OG is it needs a field added to an entity to make it groupable. So only supports fieldable entities. So far at a loss as to how that is a downside. What is a non-fieldable entity?

Also, from what i have seen so far you need a custom module for each entity type that you want to allow to be grouped. At the moment; i think there is only a module for nodes (and user's must be built in). So, for example, I don't think without writing code you can't add something like a Commerce Order to a group - but in OG, its trivial - just add the OG field to it.

#16 I absolutely see the points made here. Maybe it can be summarized in a way that OG rather behaves like "circles" or "corners" while Group rather behaves like relation building systems? Interesting enough that the much promising project Relation back in D6/7 times, which I hoped to become the reference base for core back in the days :-) is recommending on the project page a combination of Group and Dynamic Entity reference to replace Relation today. That surprised me and brought me here by typing organic into the issue search bar by Group :-)

#17 interesting and honest user perspectives review. Thanks. Just some nitpicks: what is bad on having a project adding fields to your types? Domain is doing it too and makes it well. I WOULD LOVE to see a reference module project FINALLY doing it, for me so that I do not have to care about having a 2 sides reference from both sides automatically (like CER does now additionally which needs complex setup and has no bulk update. +1 for the project exist). Non fieldable entities are non fieldable because of good reasons: the fact that they should mostly better kept untouched for internal behavior. Would love to hear which non-fieldable entities exist and why they should be groupable (in any way). It also interests me because I am supporting the final release of Domain module project massively atm.

Also, from what i have seen so far you need a custom module for each entity type that you want to allow to be grouped.

Is that still the case?