By neurojavi on

Hi all:

I'm planning to use OG in some sites I'm developing and have found that the audience selection can be improved.

* There are some problems related only to OG: For example see http://drupal.org/node/130601
Here we can talk about two things:
Do we need access to audience fields always?
Is not possible to give the admin the chance to restrict that?
If we do, how can be the nodes moved from a group to another? (this is the problem that caused SomebodySysop patch not to be committed)
And the audience has to be always a multiple select? -> That's about crossposting
I think that crossposting to more than one group is a valuable thing but it has to be used with caution.
A lot of admins wouldn't like to see some content types crossposted as this could cause, for example, that comments of one group to be seen in other groups! This can result in a lot of problems since users think their comments are only readed in their group, and they "know" the people in the group. Is very likely that they don't expect other people to read their comments.
The solution to the above is to have crossposting enabled on a content type basis. This way I can disable crosposting or story (the content type normal users use to write contents) and allow crossposting to, for example, page. The I disable comments on pages and I'm out of trouble.
This is only a example.

* And others problems are related to OG contrib modules: For example, http://drupal.org/node/156661
This last issue is common to all contrib modules that provide any kind of taxonomy managed containers (think in og_forums, og_galleries, og_vocab, og_book (I want to rewrite this since it seems to have dissappeared), etc.).
The problem here is that you can select a term (f.e. a forum) that belongs to a group and select as audience another group. This is very inconsistent and I think it makes this modules unusable in a lot of situations.
We need to provide a common and clear way for this kind of contrib modules to set the audience automatically in function of the selected forums, galleries, etc.

* So I've thinking and want to make a initial proposal as a starting point for a discussion about the best way to solve all this problems. I can help with some coding if we agree in the changes needed to be made. I would prefer to spend my time in improving the modules than in making ugly patches for my own use.

This is my proposal:

A) OG SETTINGS BY CONTENT TYPE:

- New configuration options by content type implemented in hook_form_alter for the node_type_form.
- All this data will be saved in the variables table, so no need for database mods here.
- Only applied to not omitted content types

* Crosspost allowed:
- True
- False

* Audience selection:
- Author/editor selected
- Module selected (or code driven)

* Audience required:
- True
- False

* Visibility:
- Always private
- Always public
- Author/editor select (defaults to private)
- Author/editor select (defaults to public)

B) OG GLOBAL SETTINGS:

- Remove the following settings under "Node authoring form":
- Audience checkboxes
- Visibility of posts
- Audience required

C) OG PERMISSIONS:

- New permission in hook_perm (By role)

* Manage content audience -> This will allow a user to view and change the audience of a node in any way (I think this can be improved... more fine grained? only allow to change group if no crosspost allowed?)
This permission(s) are only needed to allow changing a node to another group when no crosspost is allowed (this is a thing that moshe wants to be solved in order to restrict the audience selection form fields. See http://drupal.org/node/130601)
Perhaps SomebodySysop can help here? This will be very useful with his new module OG User Roles

D) NODE_FORM:

- Modify og_form_add_og_audience to show the audience form fields in function of the above settings for the *current content type* and *current user roles*. The detailed logic has to be discussed
- The audience form fields can be -> text (no selection available), checkbox list (crossposting allowed) or radio/select box (no crossposting)

E) NODEAPI:

- Modify the hook_nodeapi code to provide a hook to contrib modules that allows to set the audience (og_groups) in a clean way for the content types they manage. This hook will be called on insert and update.
- Modify the validate code to validate in function of the above settings...

Thanks.-

PD: Sorry if I've said any stupid thing... I have experience with PHP and drupal admin but not so much with drupal programing.
PD: Since this involves more than one module, I've filled an issue in og, og_forum and og_gallery to bring attention to this thread

⋅ Categories: Drupal 5.x, Drupal 6.x

Comments

moshe weitzman’s picture

moshe weitzman commented

thanks for thinking about this. node type specific settings make sense but we are struggling organizing the behavior today using just site-wide variables. specifically, we need to settle http://drupal.org/node/164070 and http://drupal.org/node/178811. so, we're just not ready yet for node type settings. for now, contrib modules can implement these.

i'd love to see a chart of the different combinations of settings+admin/nonadmin and what is expected of the audience field. consider the 'edit' case since thats more complicated. you might want to ignore crosspost variable for now just to stay sane.

imo, the challenge here is not code. i am having a hard time working out what he right behavior should be. once thats settled, code is easy.

unless i am mistaken, those contrib modules can already set $node->og_groups (and taxonomy) as needed using a combination of hook_form_alter and hook_nodeapi(submit). the form and nodeapi systems are very flexible.

neurojavi’s picture

neurojavi commented

You're right: It's better to clarify the current audience behavior and then discuss about audience setting per group, role, content type or whatever else...

I've read the issues http://drupal.org/node/164070 and http://drupal.org/node/178811
I'll post here my thoughts about the audience and visibility settings (if you want me to post in the previous issues, please ask me to do it. I post here because I think this a more generic discussion)

  • In the OG setting page it says:
    ...

[ ] Audience checkboxes

Show each subscribed group as a checkbox in the Audience section. This enables user to place her post into multiple groups. If unchecked, simplify the user interface by omitting the checkboxes and assuming user wants to post into the current group. Group administrators always see checkboxes.

Visibility of posts:
( ) Visible only within the targeted groups
( ) Visible within the targeted groups and on other pages
( ) Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Public.
( ) Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Private.

Determine how broadly available a given post should be when it is affiliated with a group. OG admins always see the checkbox for making a post Public. Note that changing this setting has no effect on existing posts. Re-save those posts to acquire this new setting.
  • And, when one of the two last options is selected yo have the following option in the node form: 
     Audience:
[ ] Grupo de prueba
[ ] Grupo segundo
[ ] prueba 1_1
Show this post in these groups.

[ ]Public
Show this post to everyone, or only to subscribers of the groups checked above. Posts without any groups are always Public.
  • This is a little confusing to me.
    • First a UI detail: I would add a "Visibility:" string before the []Public setting in node forms. This makes clearer that we're talking about the same setting that "Visibility of posts" (in settings page) is.
    • I think there is a mix of concepts in the public setting and its relation with audience. Now, if you want a post to be seen as not belonging to any group (let's call this a site-wide audience), you have to leave the audience empty, and then it is assumed to be public. I think this approach is a little confusing and limited.
    • You can't assign a post to a group and, at the same time, to be "site-wide". Ok, you can say that this has no sense but I think it has. Think about a post you want to be site-wide (you can see it outside any group, perhaps has a link in the main menu or it's listed in the front page) and in groupA. If you are browsing the site and click the teaser of this post in the front page, you expect to see this content without any group context, as site-wide content. And if you click this content inside a group (with a group context) you would see the content inside its group. This behavior is impossible for now. You have to leave the audience empty to make a content site-wide. And, also,when you leave audience empty, the post is assumed to be public which makes no sense for me. Public visibility only has meaning inside a group, not outside a group.
  • I have thought the following: In the audience checkboxes add a "virtual group" at the top of the list called site-wide or whatever you want. Then you can assign a post to site-wide and a group or groups without any problem (this requires changes in the code that set the context, but we're talking about design, code issues will come latter).
  • And, if we adopt the above solution, the visibility thing would be resolved as follows:
    • Visibility (public or not) will be a per group setting.
    • The audience selection will be something like this:
       Audience:
[ ] Site-wide          [X] Public  -> This is allway on! or not present at all (better)
[ ] Grupo de prueba    [ ] Public
[ ] Grupo segundo      [ ] Public
[ ] prueba 1_1         [ ] Public
Show this post out of any group (site-wide) or/and in any of the listed groups. If you check a group, then check the public box to allow the post to be viewed by non subscribers of the group or leave unchecked to allow only subscribers to see the post. Posts with site-wide audience are always Public.
    • This way we can set visibility for each group. This eliminates the problems about changing the visibility in group I'm admin and it got changed in any group the post belong to. And it makes more sense to me.
  • Then you can solve this issue http://drupal.org/node/164070 as you stated there:
    • You can set the audience at create time (if allowed in OG settings) and NOT at edit time. If you want the option to change audience settings you will have to install OG Audience (of course, this module would have to implement this changes too).
    • I think the problem you stated in #11 will be solved if the visibility setting is included in OG Audience as I've proposed.
    • I don't know if it's better to remove audience selection in the edit form only for non-author users or to all users (including author). This has to be discussed.
  • I think all this changes will solve the other issue ( http://drupal.org/node/178811 ) in a cleaner way...
  • If you all like this changes, then the changes to be made to the OG Audience module need to be discussed prior to any coding due to the dependency we will have in this module to change the audience.

Well, this are my thoughts for this week. What do you think?

PD: Sorry if something isn't clear enough. It's very difficult to me to express this subtle things in English.

moshe weitzman’s picture

moshe weitzman commented

I am interested in the 'site-wide' checkbox as part of Audience. Have to think about that.

Alas, I think the system you setup is more complicated than today, not less. You call for a Public checkbox for each group, instead of a single one applying to the post as a whole. Thats too many decisions for the author. I know what you are going for, but I'm not so satisfied.

gustav’s picture

gustav commented

I like that idea of a 'site-wide' checkbox. In addition to the advantage that Javier describes, this checkbox would also provide a mechanism for having content that is not public but available to all authenticated users, namely content with the site-wide audience checkbox checked but with the 'public' checkbox unchecked. I don't think this is currently possible, or is it?