Upgrade to Drupal 7
Amitaibu - September 3, 2009 - 22:28
| Project: | Organic groups |
| Version: | HEAD |
| Component: | og.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Amitaibu |
| Status: | needs work |
| Issue tags: | D7CX |
Description
I have started looking at the code, few thoughts so far:
Using Crell's hook_node_access, I think the whole allow/deny access logic becomes easier.
<?php
/**
* Implement hook_node_access().
*/
function og_node_access($node, $op, $account) {
$type = is_string($node) ? $node : (is_array($node) ? $node['type'] : $node->type);
$group_type = '';
if (og_is_group_type($type)) {
$group_type = 'group';
}
elseif (og_is_group_post_type($type)) {
$group_type = 'post';
}
if (!empty($group_type)) {
$func = 'og_node_access_' . $group_type . '_' . $op;
if (function_exists($func)) {
return call_user_func($func, $node, $account);
}
}
else {
return NODE_ACCESS_IGNORE;
}
}
function og_node_access_group_post_edit($node, $account) {
// In case og_access is disabled, we at least add back the edit tab for
// group admins to edit their posts.
if (og_is_group_admin($node, $account)) {
return NODE_ACCESS_ALLOW;
}
}
?>* About the group form settings (group description, appear in directory) maybe we can create those using core fields, which will later ob save us the need to add them ourself to views.
* There some functions that just should get out of og core. Wiki post for example, should move out to og_access, as it is enabled only then. This will mean we'll have to make og_types_map() pluggable.
#1
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)
#2
Wow. So, starting from the top ...
The node access pattern in the top post looks good. Note though that og_access currently handles all operations except create. It uses the node access table to do its magic, and that works well enough for me. We do need the new hook in order to start supporting the create operation. We should definately use that to restrict creation to the group post node types. We ditch the node access table entirely and rely on the hook because the hook does not affect node listings (by design; thats too slow and incompatible with pager).
When og_access module is disabled, then we do need this hook for more. We need it in order that group admins can edit any of their group posts, group members can create on the right content type posts, and group wiki posts (any group member can edit any group post).
I agree that group description could become a Field. Not sure about 'appear in directory'. Thats a bit more complex since it has perferences around in in admin/og/og.
@Crell - OG has long had an API for affiliating content with a group. It is node_save(). For affiliating a user with a group, it is og_subscribe_user(). But anyway, about the proposed direction of #1 ...
There is a lot to like in the #1 patch. I love the audience form element. The clean API is attractive too. If you are going to go this far, you might consider ending the treatment of groups as nodes. Group could be a new fieldable entity and that gives us most of what we wanted by using nodes.
I should emphasize that OG is a lot more than tagging users and content with groups. The user experience and use paradigm is really important. I think a lot of organizations approach OG and are more than happy choose a usage model from the available choices (membership request handling, private content, private group homepage, etc.). When those model don't match the need, OG is quite happy to let itself be form altered and not fuss later. It will save whatever the form says. 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. If og were only about affiliating users and content with groups, we would be using taxonomy and calling it a day.
As I mentioned before, I do have concerns about doing a major rearchitecting in 7--1. I would rather see that in 7--2. That assures that we get the first version out and fulfill our #d7cx pledge. If Amitaibu is not worried about meeting the pledge deadline (I can't imagine that D7 will release before end of year), then I'm OK with proceeding with #1.
Ping me if I can chime in again in this issue. I'm not receiving email notifications anymore.
#3
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.
#4
I've started committing my work on GitHub -- http://github.com/amitaibu/OG---Drupal7
I'll post here whenever theres enough stuff to review.
#5
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.
#6
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"
#7
If technically possible, og should be implemented according to the Composite Design Pattern.
Pic: http://www.javaworld.com/javaworld/jw-09-2002/images/jw-0913-designpatte...
#8
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()
#9
Nice Amitai!
#10
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.
#11
re-upload images properly... :/
#12
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.
#13
So we are exposing the roles of the site to the group admins? Perhaps we only do that if they have yet another permission? Seems like a lot of choices for the group admin.
#14
> 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.
#15
I've read all of the recent commit messages, and it seems that this is coming along nicely. D7 OG is going to be terrific. When you have something ready for early feedback, please let us know.
#16
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 :)
#17
I'd just like to weigh in and say that I'd really prefer a general OG-specific hook being fired; something along the lines of hook_og_event() or what not. A module that integrates that event with Rules is great, but I'd much, much much rather not rely on Rules for fundamental functionality on the sites I'm working on.
I'd prefer (for example) to implement lightweight trigger module support. With the new token support built into D7's email and message display actions, sending emails to the group administrator can be done with nothing but a trigger action, for example.
Would it be useful for me to put together the token integration for the og7?
#18
@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.
#19
yay, another major module being ported.
#20
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.
#21
Awesome. I'm all in favor of integration with popular contrib modules! I just worry when there aren't underlying hooks to tie into when needed. Thanks for the clarification!
That would be pretty crazy. I'm interested to see how that comes together. I'd like to check into things and see if it's possible to create role-specific field bundles; that would definitely be nice.
I'll keep checking in on this issue to see when it would be useful to dive in with the tokens. Thanks!
#22
During the module setup of OG, and before any other settings were touched, went to "Organic groups default permissions", and selected the "Save Permissions" button to post the form and got the line error:
Fatal error: Call to undefined function og_get_all_gids() in C:\http\drup7.dev\sites\all\modules\og\og.module on line 2108
-the function doesn't exist within the og.module file,
-searched for the function in the release 6, doesn't exist. (wanted to copy, no go)
-added a prototype of the function and was able to get the action to complete.
#23
@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.
#24
#25
Please keep issue status as is.
#26
We did some testing today at the Boston sprint. Jon and I tried to get all our notes into the Issue queue. Great work on this Amitaibu. I'm especially excited about the Group tab that appears now on group nodes with links to people, permissions and roles. That's really slick.
#27
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?