I might haven't understood if it is a "feature" or not :

My users can't create content until they have entered the "context" of a group. While this seems obvious, context of the group is hard to anticipate and lead confusion to users.

I do not know why this "group context" is necessary, but it doesn't seem to be useful at node creation, so why couldn't we change the code in "og_content_type_admin_node_add" function to simply look at the groups the user is in ($user->og_groups) and then check if one of the group has correct settings to allows (or requires) the user the right to create the node...

I did replace the content of the first "else" statement in "og_content_type_admin_node_add" with this code : ...

    $sql = "SELECT octa.types_active FROM {og_content_type_admin} octa INNER JOIN {og_uid} ogu WHERE octa.gid = ogu.nid AND ogu.nid = %d";

    foreach($user->og_groups as $gid => $group_info) {

      $sql = "SELECT octa.types_active FROM {og_content_type_admin} octa WHERE octa.gid = %d";
      $holder = db_fetch_object(db_query($sql,$gid));
    
      foreach(unserialize($holder->types_active) as $content_type => $status) {
        if (!isset($activated_types[$content_type])) {
          $activated_types[$content_type] = $status;
          continue;
        };
      
        $activated_types[$content_type] = max($activated_types[$content_type], $status);
      };

    };

    $look_at_allowed = 0;

which allows what I was expecting : standard links to content creation as "Create Content" and links provided in "forum" module are now working without having to find the correct context...

Could this be integrated in the developpement release (after review...) or did I miss the point ?

Comments

vaab’s picture

vaab commented

sorry for the first code line (starting with '$sql =' ) which obviously popped out somewhere AND isn't useful.

rconstantine’s picture

rconstantine commented
Status: Active » Closed (works as designed)

Yeah, you pretty much missed the point. The point is to show the user what they can do from their current location (specific group or site-wide). I am mainly using this because I have content types that are specific to certain groups. It therefore does not make sense to allow the creation of type XYZ which is specific to group A while in group B - so I remove all links related to XYZ while in group B and even disable node creation from there as well because there is no way to auto-set the OG audience to a group you aren't currently in.

Some people use this module to limit forums to groups and eliminate forums from the site-level. If there are no site-level forums, it doesn't make sense to have links to create posts to them. Others use this module to force all content to be created in a group, in which case they often hide the OG audience interface so that the audience is auto-selected and can't be changed by the user.

What your code does is check to see if the user can create a content type SOMEWHERE, and if so, you are allowing them to post that type ANYWHERE; unless I'm mistaken. So given my example above, if a user can create XYZ while in group A, your code now allows them to post XYZ in group B, which should not be allowed.

Needless to say, this breaks the whole point of this module, so I won't be adding it to any future versions.

If you feel your code does not break the behavior I intended, please explain.

vaab’s picture

vaab commented

What your code does is check to see if the user can create a content type SOMEWHERE, and if so, you are allowing them to post that type ANYWHERE; unless I'm mistaken. So given my example above, if a user can create XYZ while in group A, your code now allows them to post XYZ in group B, which should not be allowed.

The audience box, in the node creation page, is correctly set to ONLY the groups you are in AND that have the permission to create this node. I've checked this.

I can understand the use case you have explained.

I am mainly using this because I have content types that are specific to certain groups. It therefore does not make sense to allow the creation of type XYZ which is specific to group A while in group B - so I remove all links related to XYZ while in group B

We all use your module because we "have content types that are specific to certain groups". And it doesn't imply that we want that user U has to change something like a context, to use his rights to create type XYZ has member of group A if he was "in" something like the context of group B.

You added the notion of "context" which I understand as a feature you wanted to add. I understand how useful it can be in some cases. May I suggest that default wider behavior as "create content" in forum or in menu may optionaly not be broken by your module ?.

Your perspective of organic group seems to be correlated to "locations" (or context) in your site : you must enter the location to be then asked for action in this group. In my views OG are more than just a location holder. Shouldn't the entire power of OG be brought to your OG Content Type module ?

and even disable node creation from there as well because there is no way to auto-set the OG audience to a group you aren't currently in.

This might not be a problem for some community site model. I understand that it is a problem for some views... I'm willing to help you code parts that will keep all model usable : we could use options in module configuration.

Let me explain my case :

Drupal role model is very limited, especially if you want a multi-community site. My site is centered on the individual that can create or join communities. Using OG to emulate what role should have been is very powerfull in these cases.

My main problem is that your module break lots of default behaviors (create contents in menu OR in forum ...) , and I cannot use it this way. It is difficult to understand that you HAD to break all these simple actions because it isn't said in the description of your module AND it is not necessary from a global point of view. What I understand is that what forced you to break behaviors is not by design of the OG Content Type public goal, but maybe it came from your needs in your particular site you have in your head which implies the use of OG as "locations". The resulting situation is that it is impossible to use the fondamental feature that this module bring (allow creation of content types by OG) without having to use your OG model view (with location and context).

But I feel that these two component are not so intertwingled, this explains why I could "correct" the behavior with very few glances and modification in your code. This makes me think that maybe a very little modification could allow both views. Or maybe it could be separated in two modules. A OG_ Content Types, and a "OG Context" module ... How do you feel on this topic ?

These notions aren't really simple to explain, so I hope that you have understood my point of view ;)...

rconstantine’s picture

rconstantine commented
Status: Closed (works as designed) » Postponed

I'm switching this to postponed so I can give it further thought.

rconstantine’s picture

rconstantine commented
Status: Postponed » Closed (works as designed)

After further thought, I won't be changing this.

I did think of another point of view perhaps. The main issue above seems to be that users are "unable" to create content outside of groups. That should not be the case at all with this module. The "site-wide" group specifically allows users to create a given content type from anywhere in the site. This, of course, puts the responsibility on them to set the OG "audience" correctly if they are creating an OG node from outside of that OG.

So in other words, having experimented with the current module, I'm not seeing all of the short comings that were mentioned above.

However, forums were mentioned, which brings with it a whole different set of problems. See that issue queue for discussions and links to other discussions about "audience" and "public" issues. I'll be tackling the "public" - as in "publicly viewable/privately postable group forums" - soon.