Upgrade to Drupal 7 (Organic Groups)

I have started working on this issue. Here is a little background:

* I had a discussion with Crell about how OG should look in D7, with all the new hook_node_access() stuff. He suggested abstracting OG even more by having an API that allows associating content (user, nodes) with a group node.
* Moshe asked me to help upgrading to D7, a simple "Deadwood" upgrade. However since we have enough time until D7 release, I thought we should try and have a proper upgrade.

The attached patch is far from being completed, however SCRUM is something I learned in drupalCon ;)

og.module is an API, that:
- allows associating content with group nodes.
- Defines an og_audience widget.
- allows adding an OG audience field to nodes.
- Some testing, no full code coverage yet.

As there is no restriction to the content type associated with a group, it means also groups can be associated with a group (to be extended by og_subgroups); and any other identifiable content (to be extended og_vocab).

og_ui.module (which isn't written yet) should provide the menu items like join, remove from group, etc'

og_access.module (which isn't written yet) should provide a flexible permissions system per group, and allow other modules to add more roles, so we'll be able to have just a "regular" user and an "admin" user (might make og_user_roles obsolete)

Thanks Moshe for your comments.

> @Crell - OG has long had an API for affiliating content with a group.

Indeed, but with the proposed patch also vocabs for example can be affiliated with a group.

> My point is that the og_ui module is really important, and we won't have a luxury here of focusing on a core API and leaving the rest for "add-on modules" like og_ui

I fully agree that we need to keep the functionality in core. However moving the UI stuff to og_ui (which will be packaged with with OG itself), is just for a better separation between the notion of grouping enteties together (which can be later on extended by other modules for their own needs) and the handeling of subscriptions and user actions in the groups.

> (I can't imagine that D7 will release before end of year), then I'm OK with proceeding with #1.

It's a valid concern, which I also have. Assuming D7 will be released on 2010, let's call 15-NOV a go-no-go point where we decide if the refactoring is going the right direction and will be ready on time. Otherwise, I'll work on a straight "deadwood" upgrade.

I've started committing my work on GitHub -- http://github.com/amitaibu/OG---Drupal7

I'll post here whenever theres enough stuff to review.

quick update:
1) I have merged og and og_ui as it no longer really made sense separating those. The reason is that OG is now relying on fields API. you can see in og.fields.inc that we have og_audience field, that can be assigned to nodes as-well as users (or any fieldable entity).
2) OG now has the concept of data per group. Data is an array with arbitrary information. OG, by default adds some roles and permissions.
3) og.api.php is being built along writing the module - so it's easier to see how other modules can hook into OG.
4) No proper test coverage yet, since the modules merge, but I'm going to pick this one up.

I had an interesting progress which I think that simplifies the way OG deals with its tasks.

The idea
1) We introduce the concept of roles and permissions to OG core (lots of copy paste from user.module -- which gives the same look & feel like Drupal core).
2) All menu items are sent to the access callback og_access(), which imitates hook_node_access() in terms of allowing other modules to allow or deny access.
3) OG has anonymous member role for non-mermbers.

This will allow us for example:
* og_selective (e.g. open, moderated, invite only) field can be replaced by the permission "subscribe without approval".
* private groups are also a permission "view GROUP content"

I have committed a new version that you can manage your group's users via og/%node/admin/people

@Amir,
It is now possible to do it -- as the group usage is divided into two variables -- see og_is_group_post() and og_is_group_post_type()

I have added the ability to define permissions on the permissions. Look at the images, it will make more sense.

Image1 is a site admin, that can define on a per group basis which permissions the group manager will be able to set.
image2 shows the group permissions as the group admins sees them.

This means settings such as "show group in registration - always/ never/ default yes/ default no" become a permission as-well.
Next step is create a page for the site admin to define the group defaults - i.e. the permissions a new group will get.

re-upload images properly... :/

I have implemented the concept of default permissions - those are the permissions that would be set on the creation of new groups.
There is also the option to "bulk update" permissions on existing groups.

> Seems like a lot of choices for the group admin.

Indeed, it can become a longlist - for that the *site* admin can set which permissions the *group* admin can see and set. This is no doubt another case of flexibility Vs complexity, but I think that since OG is copying the Drupal core way of doind things it will reduce the learning curve.
With that said, I'm of course open to ideas and comments :)

Also I plan to have sensible default pemissions, so the site admin won't need to feedle too much with permissions when setings up OG.

Ok, I think we are on schedule. It's 1-NOV, and OG is ready for an early feedback and testing.
You can grab OG7 from github (as git clone or as a zip/ tar) -- http://github.com/amitaibu/OG---Drupal7

TODOS:
- Upgrade path from D6 (i.e. populating OG6 data into field API).
- Views & Rules integration. Rules is the basis of all events driven actions. This means that OG has no drupal_set_message(), so for example when a user will subscribe to group, a rule will be invoked. That rule can show a message on the site, send an email, etc'.
- SimpleTests. 100% coverage is a good goal :)
- Bug fixes.

Some help on how to test:
- Install OG.
- Create a content type, that is a group type, and one that is a group post type. Or, you can create a single content type and set it to be group type and group posts (i.e. group of groups).
- Create a group node.
- Notice the group tab that is added. In that tab you can set the roles and permissions of the group.
- Create a dummy user, that will subscribe to the group.
- In the group tab >> People, you can approve, deny or ban member(s) from the group. You can assign or revoke group roles.
- You can set default permissions in admin/config/og/permissions - those permissions wil be set whenever a new group is created. You can also "Bulk update" permissions on all existing groups.
- Next, install og_access and og_register. OG access will add a field to set the group visibility. OG register will add a field that will allow subscribing to the group on user registration.

If there are any question, comments I'm here :)

@eaton
> something along the lines of hook_og_event()

Indeed, og_invoke_event() will take care of invoking a hook as-well.

> Would it be useful for me to put together the token integration for the og7?

First - yes, and thank you :)
Second - I'd prefer if it could be in about a week, because I plan to abstract a bit the code -- currently only a node can be a group. I'd like to make it possible that any fieldable entity will become a group, so for example just by creating a user, one will be able to assign group posts and taxonomy terms to it.

I'm doing some important changes to allow any fieldable entity will be able to be a group type. I have committed a few and it's not complete yet, so the module is currently going through an un-testable short period...

I think this will extend OG to become an even more powerful ACL/ clustering-content-together module.

@jjmackow,

Thanks for going over the code. It still "needs work" as I've done some changes (any fieldable object can be a group, not only nodes).
I think i'll be able to get it back to "needs review" in a few days, most issues are already ok.

Please keep issue status as is.

Any fieldable entity's bundle can now be a group and a group post. We need a way of adding fields to those bundles. In the image you can see there's an overview page with group and group types, listing all the bundles, and all the fields that can be attached to them.

Every module can implement a hook to add it's fields

/**
 * Implement og_get_group_fields().
 */
function og_og_get_group_fields() {
  return array(
    'group' => array(
      'og_group' => array(
        'title' => t('Group type'),
        'callback' => 'og_create_fields_group',
        'field' => 'og_group',
      ),
    ),
    'group post' => array(
      'og_audience' => array(
        'title' => t('Groups audience'),
        'callback' => 'og_create_fields_group_posts',
        'field' => 'og_audience',
       ),
     ),
  );
}

* The feature currently only adds fields, it doesn't remove them.

--
Anyone care to start a review?

I intend to add it to the permissions page for permissions that are dependent on each other. Other than that so far field API is doing all the work.

I'm also thinking of moving og_determine_context() and make it a CTools plugin - which I think is a better place for it.

> does this still try to incorporate og_user_roles?

Yes. The base of OG is the ability to associate content to a group. On top of that we have the role and permissions.

> it's not really having the extent of altering any user's privileges and permissions within a group.
...
> most sites just want groups, without introducing a separate permissions layer on top of Drupal's default permission system.

If I understand your concern correctly - the site admin can set which privileges (if any) a group admin can assign to other admins.

> We'd need a ton of tests

I like tests ;)

--
@sun,
I believe lots of code/ patterns I've used from Drupal core have your signature on it, so getting a review/ help from you is always welcomed!

@Crell,
Thanks, I now only hope my code will live the expectations ;) .btw, Amitai not Amit --:)

@eaton,
If you are still there, and have some time for og tokens...

With much help from Moses Elias -- README.txt Reviewers, where are you? :)

I have created a new project called "group" ( http://drupal.org/project/group ) for the following reasons:

1) A group will be an entity, that you can group_load(), just as node_load() and user_load().
2) Core calls the module node, not nodes.
3) In Drupal we don't use abbreviations.

@Dave Reid,
> They're not following dead link
What dead links?

> most of them follow progress here on drupal.org, not github.
Right, but for now in order to speed up development I prefer using git (allows me to have "experimental" branches). I will of course commit changes stuff to CVS (As I have done until now).

@sun,
> I can only hope that you/"we" discussed this in detail prior that move.

I haven't renamed anything yet -- just saved a place, and wrote the reasons for the move here, so it's open for discussion. If there's a good reason for not doing it, then the "price" will be an obsolete project in projects/group.
I think that since OG7 tries to fix all the cruft OG has gotten along the years, renaming to follow core patterns is except-able.
As always, I'm open -- and would be happy -- to hear opinions.

@Dave,
You are right, as I renamed the project on github, I thought it will redirect the link. Here's the updated link -- http://github.com/amitaibu/group

@johngriffin,
I've committed the code to CVS in http://drupal.org/project/group

I'm closing this issue in favor of issues in Group project.

> so will you be releasing a d7 dev version of og soon

As soon as Drupal will be released.

Closing issue in favor of more specific issues.