Trying to program with og's node_access - OG not saving og_forum nodes to og_ancestry

Um, so I see that it looks like og_save_ancestry should be taking care of things, right? In og_nodeapi's insert case, where the node type is not a group type, and where it also isn't an omitted type, it is called directly.

I've double checked my installations and forum types are neither group types nor omitted types, so it should be firing, right?

...

Okay, I just checked, and for users that can see the audience selector, nodes are being added to og_ancestry with no problems and the nodes are not viewable by unauthorized users. SO that case is working. But for users where the audience selector is supposed to be automatic and hidden, those nodes are not being added and the $node->og_groups array is empty when the submission process gets to og_save_ancestry. Any ideas?

In this code:

my test case has $options >1, and $required ==1, so the first if is passed up and I enter the elseif($gids) portion.

This portion sets $groups correctly.

Then in this code:

my test case skips the if($simple) case because that is only set in the first case above, and enters the second case elseif ($cnt = count($options)).

However, I would expect the regular audience checkboxes to be displayed in this case, which they are not.

Notice that you have two lines of '#required' => $required,.

So should $simple be set in the case that my code uses? Or should there be an additional case just before elseif($gids) that reads elseif($gids && $required) wherein it would set $simple?

Line number is 1560 if you've got the same version. I think I had the latest at the time of this post. At that line number, you should find yourself in the middle of the first code listed in #4, above. Add the code from #5 on line 1560. You will then have four 'else' statements instead of three.

Sorry everybody for not rolling a proper patch. I've been in a hurry lately.

Yes, you'll need to re-save in order for the nodes to get put into the og_ancestry table. Lame, huh? You may want to send your group owners a note to help you out in this task.

seem slike this is a support request that got resolved. there is no patch here.

posting a code sample is not a patch. see diffandpatch. so i assumed you had a support question and found an answer.

i see your code fragment but i don't see an explanation of why current code is inadequate for your module and how this fragment helps. "i did this and it worked" is not adequate.

Okay, I'm not sure about the first two lines of this patch or how I would have done things differently to get them right, but the file version number is 1.368 and was a dev version, I think, from August? I think that dev had solved a particular issue I was having which is why I am using it. If you'd rather, I could probably do one with the latest RC version.

Attachment	Size
og.1.368.patch	836 bytes

I really don't mean to keep bothering you about this, but I just haven't yet gotten the impression that you're trying to understand what I'm saying or see things from my point of view and I'm not sure why that is.

In looking at my previous patch, I realized that the same thing can be done with an addition of only three lines of code, so I'm attaching another, smaller patch.

Of course I know that hook_form_alter can alter forms, and I know that I can override the submit and validate functions by setting #validate and #submit. But it just doesn't make sense to me to add 100+ lines of code to og_forum if three lines added to og will do the trick. Plenty of other modules make an effort to work together and I thought that since og_forum used to be distributed with og that there wouldn't be a problem with the relationship there.

Anyway, this will be the last I'll say on this matter and let you be if that's what you choose, but I really wish you'd reconsider. Thanks for your time and continued work on OG.

Attachment	Size
og_and_og_forum_compat.patch	664 bytes

Don't you think it's kind of funny when two people are trying to get their points across and in turn trying to understand the other person and it just isn't working? I do.

Anyway, thanks for hanging in there with me.

To (hopefully) clarify the patch: og_forum requires that users NOT be allowed to cross post forum topics. The reasons are many, but to sum them up, it would be a huge pain in the butt to code to allow it and there are permission issues with users seeing what they ought not to see, and so on and so forth.

Given that they cannot cross post, that means that their only audience choice is the group that they are presently in (if they are within a group). However, that means that there are technically more than one choice of groups - they just can't make that choice themselves as og_forum chooses for them.

So, if we look at the first code snippet in #4 above, count($options) will never == 1. Otherwise, if you only have one group, why install og_forum at all? But $gids will be set because we have a group context inside of a group forum.

Skipping down to the second code snippet in #4 above, the BEHAVIOR of the code executed when $simple is TRUE is what og_forum needs. If it is not TRUE, then the form is presented to the user, which we don't want to do.

My attempts to form_alter are not working:

Other combinations were attempted including not unsetting #default_value, not setting #value, setting og_groups' #access to 0, and others. Still, the value is not saved and these nodes are not entered into the og_ancestry table.

So back to snippet one from #4: og_forum has $gids, $required ==1, $options > 1, and we do see the nodes in og_ancestry if $simple is TRUE. So I figured that the last patch I posted is all I needed to get things right.

You mention checking other cases:
simple: simple means that the user can't choose, but the audience auto-selected for him is displayed. That's what og_forum wants if audience is required.
required: if audience is required, the user cannot choose where to place the forum topic as the forum itself belongs to the group where the user is presently located if $gids exists. If the user is outside the group, then he can choose which group/forum to place the topic in and there won't be a $gids.
admin/non admin: admins always see the audience selector, my patch should only apply to non-admins.
etc: IIRC, other content types are not affected. However, if they were, a change to the patch testing the content type in addition to $required wouldn't be difficult or add further lines of code. It would simply be if($required && [the content type is a forum topic]) { $simple ==TRUE; }

Did I finally explain myself? The written word, especially in a time-delayed back-and-forth like this format is, isn't always the best medium for clear communication.

so, what is the current status of this issue?

I am currently using og 4.1 and og forums and really need to have the group forums private.

will this patch help me with this issue? Or is this someplace else i may find a solution?

thanks so much for any info or help you can provide.

I'll take a look at this link you've provided Moshe. For the record, I did state in #18 that perhaps 'required' and 'gid' weren't enough and that 'is a forum topic' should be added to the condition. Also, as I recall, one of my later patches removed the code redundancy so that there was only one line of code added, rather than the duplication of an entire block of code like my initial post had.

The bottom line is the patch submitted here would break lots of use cases for og. Further, I am not inclined to adding forum specific code in og.

From my perspective, forum.module as it stands in D5 is just about dead given what Views can do. Forum module was reduced significantly in D6 with http://drupal.org/node/20295. It is now just navigation and an easier admin UI than whats provided by taxonomy itself.

"But the real issue that caused me to investigate the route I'm taking above is the problem of forum topics not being included in the og_ancestry table and therefore not really being associated with ANY group, even if posted to only one forum and one group. I don't see that the discussion you linked to had anything to do with og_ancestry."

I really can't walk you through the whole node request flow. Thats what debuggers excel at. see og_nodeapi('submit') which goes to call og_submit_group(). this is where $node gets prepped before a save. later, og_nodeapi('insert') is called and that calls og_save_ancestry unless your node type has been omitted. So be sure $node looks the way it is supposed to at that point.

Using og2list is very dependent on og_forum and therefore forum modules... You cannot just write them off.

Mack and I were actually just discussing over IM whether it would be worthwhile removing the og_forum dependency from og2list. We are using og2list for all sorts of content types, including CCK types (where we render the content using code borrowed from node_render).

Anyway, really it seems like the only place og_forum comes into play is when og2list needs to get the group forum for NEW mails coming in (which are saved with node_save() not comment_save(), and therefore need to have a type and taxonomy. In at lest the 1.3 version of og_forum, the og_forum_get_forum() was returning the container term, not the forum term - much like when a post came from the web and you had to expand the forum section and make sure the container wasn't selected but instead the forum itself under the container was selected).

Anyway for our private version I just reimplemented this function so it would do the query in the opposite order, thus defaulting to the group forum not the container:

So in my version we aren't even really using og_forum, other than expecting the og_term to be there. This whole dependency could easily be avoided by making it views friendly instead, and having some sort of per group configuration where you could set what content type you wanted new nodes to come in as and what tids to come up. Given the direction of core's forum support in D6, this would be a sensible approach if and when we do the fabled Great og2list Rewrite (I think this will have to happen for D6 to make og2list more concise and usable. There is also a ton of old and poorly organized code that could really be done a lot better. I think the og_forum dependency is one of these issues).

Anwyay just wanted to chime in there and clarify my understanding of how og2list depends on og_forum. Is there any other spot that you know of Dmitriy? Or anyone else reading? If there ARE no other dependencies, maybe we should consider decoupling og2list in the drupal 5 version? Anyway that belongs in a separate issue but it seemed relevant to this discussion.

Sorry this is totally off topic to this thread, but just to answer Dmitriy and then no more og2list talk I promise...

also I have some useful info relevant to this thread at the end.

re: og2list activity and backports:
I need to actually get a stable internal version before I can look at backporting everything at this point... that is my primary mandate as Post Carbon is sponsoring the development and still needs to use it ASAP on their production sites.

We are real real real close to that now, been publically beta testing it with select groups and real users for several months since we last spoke with you about it... there are a couple nagging bugs still fighting us but I am trying to get those all knocked off this week! But, I've said that before ;) more may come up! Realistically though I can't see how we can't have it alive and stable by the end of the year.

At that point I will look into trying to move forward with the CVS version, while releasing our private one available to any who want to use that one too. Given that we have been doing real testing with real users for 3 months on the private one, I would expect that is the version people would like to use. But I appreciate the atomic patch argument too, if Post Carbon is willing to fund it. However I thin kthey are likely to instead choose sponsoring a complete Drupal 6 rewrite, while allowing people to use their private version released independently. This would probably cost less and get the community a whole lot more, than spending 6+ months backporting the changes into this version, which will then still be in need of a rewrite... too many things are just too messy with how it's done now.

An alternative is of course releasing the postcarbon private version as a 5.x-2.0 branch and doing all the support requests via drupal.org. That would be my preference, I know everyone else is cautious about atomic patches but I honestly don't think postcarbon will pay to do it, and I sure don't have the time to do it on my own time. I will be organzing a public demonstration of the private version as soon as those last few bugs are fixed, hosted on the postcarbon server, at which point people can try it out for themselves and see the new features and we can decide as a group how it will go forward.

I will be definitely backporting a couple of serious bug fixes to the 5.x-head version, even if the project remains abandoned and unmaintained.

But honestly, the CVS version is so lacking in security features and rendering capability that it's not all that useful in a real production site. It does not support multiple domains or multiple sites per postfix server. It does not properly filter spam attempts. It does not do any logging on the perl side. The list goes on and on. Maybe an internal intranet with more tech savvy users might be able to use it, but definitely not he general public class of users. We spent a whole year of private development and testing (which moves at about 10x+ the pace of public drupal.org devleopment and patching and design-by-comittee) and still it's not quite production ready!

In a perfect world, there would be time for all of these things.. it would work, we would have a team of developers who could backport, review and test patches, and all this could happen for a stable 5.x version while we also at the same time began work on a rewrite for a d6 version. But alas it's not a perfect world... there are numerous patches awaiting testing in the issue queue that no one is testing, the maintainer is totally absent and can't even test the project because he has no test environment, and nothing is really going anywhere fast. It is not an encouraging situation to begin backporting $50,000 plus of development work patch by patch.... I still believe it's in the interests of the community as a whole to just 2.0 it and anyone who is concerned too much by atomic patching to use it, well then they can spearhead diffing it and backporting the features one by one and testing them and committing them to the 1.x branch, to become 5.x-1.1 and 5.x-1.2, etc. I see this happen regularly on other projects... rconstantine did it with og_forum 1.3 - 2.x for instance. I'd love everyone to feel warm and comfortable and fuzzy but that is perfect world stuff I think unless a lot more people step up to the plate and start actually helping with og2list.... right now I think the best way to more people using it and getting involved would be a version that is actually functional enough to use on a public site, and that is what post carbon spent a lot of effort and money developing.

Anyway that is my understanding of the politics of things with respect to the atomic patches etc etc. Really if I get this private version working that's great. If other people want to use it, that's great too. if we can get it back into drupal.org as a new version, also great... but ultimately it is not a higher priority to post carbon than a working version for them and a better working version for drupal 6 that they can continue to use in the future. Forking the project doesn't really make sense as we are doing the same thing... so only a new version seems to make sense to me. Post Carbon is willing to continue funding and own the cost of developing and supporting future og2list versions... but not if it involves wasting a fortune and months or possibly years of real world time and effort in what is literally going backwards for them. If it ends up being a totally private version they maintain then so be it, but really, what is the point in that?

Anyway, small novel but it's been a while since I expounded the issues and I guess a lot more people will see them here in an og thread... sorry for that aside.... now, as promised, back to this issue...

I'm not sure how it fits in, but for us new mails that come from og2list and are posted into a private group (using the private groups patch at drupal.org/83005), end up private, even if you go right to the node itself.

example: http://beta.relocalize.net/is_it_still_working - a private forum post that came through og2list to a group that was marked private. So the default audience fields are getting set right for og2list. I am pretty sure this beahviour would be the same for the CVS HEAD version of og2list as well as our private version, I don't recall putting in any special handling to make it behave that way, it's the private groups patch doing the work. So if you are concerned about og2list and group node privacy, there is one answer for you, it's working great for us in production on multiple sites with tens of users (and soon to be live on over 200 groups with > 1000 users). Perhaps the private groups patch would serve your needs if you are only concerned with og2list and not forum postings on the web (it handles that great too.. the only thing it does not do is affect visilibility on existing group content)

ok, this will be a patch distributed by og_forum

Since this is now covered in the og_forum README, I'm closing this issue.

Could you roll a proper patch file (against latest OG release) to be distributed with with OG Forum module?

If I can get around to it. I just double-checked what I wrote in the README and don't see how this could be a simpler process. It's actually easier than patching a file with a proper patch! You add three lines of code into the specified function in the specified location. That's it.

The HOW to do it is this:
1) using your favorite text editor, open the README file.
2) using your favorite text editor, open the og.module file.
3) from the README file, copy the function name listed that is to be modifed.
4) in the og.module file, hit ctrl-f which is usually the 'find' function for a text editor.
5) in the og.module file, hit ctlr-v which is usually the 'paste' function for a text editor.
6) in the og.module file, hit enter to do the search; make sure you find the function declaration.
7) in the og.module file, scroll down to find the 'surrounding code' as mentioned in the README; naturally, the changes won't be there yet since you didn't yet add them.
8) in the og.module file, find the last line before the comment as mentioned in the README; the comment is this thingy: /***********OG_FORUM NEEDS THE NEXT IF CLAUSE*********************************/, so you are looking for a closing brace "}" without the quotes which follows this line $groups = array_intersect($gids, array_keys($options));
9) in the og.module file, place your cursor at the end of the line you found.
10) in the og.module file, hit enter to be sure you're on a new line.
11) in the README file, copy the three lines of code which are designated as being needed - namely these:

12) in the og.module file, hit ctrl-v which is usually the 'paste' function for a text editor.
13) in the og.module file, hit ctrl-s which is usually the 'save' function for a text editor.
14) close both documents in your text editor by clicking the 'X' in one of the top corners.

Your patch looks fine. Clearly we have some philosophical differences, but I don't have a problem including this in the tarball. The only problem of course will be that as soon as OG is updated, this patch won't work.

I'm curious to know what kinds of "complex configurations" you come across that make the manual patch process difficult. I'm not being flip; I'm really curious. You see, I usually update one common base copy on a local machine (which has all modules I've ever used in one install, and which is backed up via SVN) and then upload the fixed copy to the sites that use it. So whether by hand or by machine, there isn't much to this fix.

I also suppose that by keeping installations in SVN, I really only apply patches once, even if the underlying module changes because when I update a module, I always run the old and new versions through a visual diff program and look at what changed. If a patch isn't needed, then I don't do anything. But if it needs to carry over, it's easy to incorporate. This is especially helpful when module that have patches for other modules aren't updated often, if at all, and so their patches will no longer apply cleanly.

Anyway, thanks for the patch. I'll also update the README and indicate which version of OG this applies to. I can't promise that I'll update the patch as often as OG changes.

Marking RTBC for the next OG Forum commit.

I would also recommend streamlining OG Forum readme to replace manual instructions with direction to use the patch file.

OK. I would still list the patch file as the preferred option and put all manual instructions into an appendix / separate section.

This is how every other module that distributes patches is documented (advcache, memcache, etc).

Bump. To include in the next og_forum commit batch.

Please download the latest development snapshop to resolve this issue , thanks.