Project nodes as OG: keeping project* content associated with both project and group

i'm not clear on the problem here. can you try to explain in more detail? maybe walk through a scenario where the problem occurs?

there's still not enough information here for me to properly address the issue. please walk through an entire scenario. how are things set up exactly? what link are you trying? what exactly do you mean by 'the link fails'?

/node/add/book?gids[]=3 <-- but this link works properly?

should probably go here instead...

Ok, that all makes sense, but I don't really know where it should be fixed. Hate to say it, but I think the code really at fault here is project_release.module's handling of this... Basically, we need to know the nid of the project node that's the parent for the release node. Currently, we assume it must be in the URL via that special link on the project nodes, and if it's not in the URL, we give up. Note that this is very different from OG's ?gid[]=... stuff to associate a new node with the right groups (via OG's own DB tables). In theory, once a release node exists, it could move to other groups, but it can never change what project it belongs to. Your case is weird, since the project *is* the group (clever, don't get me wrong, but weird from the perspective of some of the code). So, OG assumes it can craft the links in the way it expects, and project_release thinks it can do the same, but they conflict.

So, og_project makes sense as a good place to hack around this problem, since it's designed to be a glue module to get these other two beasts to work together nicely in situations like this where they don't...

Arguably, the real culprit here is project_release -- if we don't have the project nid in the URL, we should just have an initial page on the node form to select the project (just like on new issues). However, it still wouldn't be ideal from the perspective of OG, since the little block of menu links for adding new content still won't have the right thing in the URL to pre-select the right project. :( Ok, I guess some kind of ugly hack in og_project really is the only way to solve this.

That said, this particular use-case for og_project isn't something I personally need at all on my OG + project sites, so I'm not going to work on this on my own. If you really want this fixed, you either need to a) write the patch yourself, b) hire me to work on this, or c) hire someone else to write the code, since I won't be doing this just for fun. ;)

Cheers,
-Derek

It works like this for me:

Link shown is:
http://www.drupalmty.com/node/add/project_issue?gids[]=7

when I click it, I get directed to:

http://www.drupalmty.com/node/add/project-issue

which shows this:

"Invalid project selected."

.. and a pulldown to select the project.

HOWEVER, trying some alternative URLs, I found that this does work:

http://www.drupalmty.com/node/add/project_issue/khub

which brings up the create issue form correctly. My project URL (and group node) is: http://www.drupalmty.com/project/khub

Hope this helps at all...

Using the hooks Project module generously provides, we've created another glue module to allow project pages to also be organic group pages, with the function described here to add and modify project issue creation links to work with organic groups (and, unrelated, add my own long-time wish for an "all issues" link).

Also in this module, which we are calling "organic_project," we allow users with access/membership to a group-project to assign issues to other members of the group-project.

We just did this for Agaric's project tracking site and the code isn't polished yet, but the functionality feels fairly solid and general already.

Should these be contributed as patches to og_project or as another module?

^{benjamin, Agaric Design Collective}

Yes, patches for og_project please. ;) That's exactly what og_project is for (though I haven't touched that module in ages). I'd rather there was a single og + project glue module instead of a fork. Thanks!

Correct link for that first one:
http://agaricdesign.com/note/adding-and-modifying-organic-group-action-c...

Will roll into patches for review. To be clear, I think all of these contributions rely on configuring project nodes and organic group nodes to be one and the same. So testing for that or generalizing these functions I think needs to be resolved.

^{benjamin, Agaric Design Collective}

bump/subscribe.

@Benjamin - if you could post your code as a patch that would be great. I agree with you that the project node = group node is a reasonable way to go but should ideally be tested to confirm it's the case. I think that this code could just freak out if that's not the case - let the person who puts multiple projects inside a group worry about how to fix it ;)

I'd like to have code in og_project that tests if project nodes are themselves organic groups, and in that case, we automatically assign the audience to the project node that issues (and releases) are associated with, instead of providing an audience UI (either via the URL or on the issue/release forms).

Thoughts?

That would be fine for my use of the module. I can imagine a scenario where people want the issue to be in multiple groups if, for example, they use groups as projects but also have other groups that are not tied to projects... perhaps the audience selectbox could just have nids that are both projects AND groups removed from it?

Sadly, looks like Benjamin is never going to share his code for this. :( I needed it, so I started working on it.

Here's an initial patch that adds a setting to let sites automatically assign the OG audience for release nodes to point to the project node that the release is associated with. This is only an option if project nodes are configured as OG group nodes. This "needs review" only since I'd like some other eyes -- it definitely needs work:

A) The admin setting help text and descriptions here are absolutely terrible. Help! ;)

B) It doesn't yet alter the links in the OG block to add the project nid to the URL for creating the release, instead of the ?gids[]=1 stuff (which we no longer need or care about once this setting is enabled).

I'll do something nearly identical for issues once this is happy...

How's this?

"Your site is configured with Project nodes as Organic Groups. Projects can also have other nodes associated with them, which you may want to have automatically posted to the corresponding Organic Group."

The only thing I'd change about the blurb below the checkbox is the word "each" to "the"

Yay, vastly better. ;) Thanks! Attached patch incorporates steph's lovely text, and includes support for issue nodes, too. All that remains is (B), though I think I could commit this as-is for now and handle (B) in a follow-up patch. Anyone care to test/review the code?

Final(?) patch that implements hook_og_links_alter() to fix (B). Anyone care to test/confirm?

p.s. While working on this, I noticed #536340: Title attribute for links in OG details block not showing due to misuse of D6 l() API....

I noticed a small problem with this settings page. I'm working with a site where releases should be associated with groups, but issues are not going to be associated with groups at all. On a site like that, you don't want a checkbox here about automatically setting the OG audience on issues, since there's no such field. Instead, we want some text saying "issues can't be in groups" and a link to the page to edit the project_issue node type (which sets a destination and brings you back here if you submit the other form).

See attached patch and screenshot.

Any other reviews/objections before I commit this?

Thanks!
-Derek

Committed to HEAD.

Ahh, thought of one case where this doesn't get it right -- whenever an issue followup comment moves an issue from one project to another, we need to do something (presumably just re-audience) the issue...

True.

Also, IMO the "Assigned to" dropdown should contain only members of the current group. So, if a project is changed in a comment then that dropdown should get changed as well.

@greggles: That's your issue over at #311953: limit assignees to users in the group. Let's keep that a separate feature request so this doesn't get overly-complicated. Thanks. ;)

Here's a patch that fixes the issue dww mentioned in #24.

I don't understand why we have to assume 1:1 project:group here. Instead of clobbering all, why not just unset the old group and add the new one?

Thanks!
-Derek

I don't think we can assume that unsetting the old group is the intended behavior. As I wrote this patch I thought for a while about what the "right thing" to do is if you wanted to keep this in groups and I don't think we can or should try to guess about that. Instead, I think that if you don't have the 1-1 tie then we should present the whole audience UI inside the comment box as #140951: issue followups can't change OG settings (neither groups nor public vs. private) plans to do.

I feel like the optional nature of the 1-1 tie overcomplicates the module making it harder to use and write code for but that should really be decided on its own (I created a new issue for it: #962446: 1-1 requirement (for now)).

Given #962446: 1-1 requirement (for now) og_project can (at least for now) assume 1:1. However, we need a // 1:1 code comment here so still needs work (I can just add it when committing if everything else is tested and working fine). I also prefer a newline at the end of my files. ;)

subscribing

I'm not yet sure if it's because of this code or because of something missing in this code, but it seems that when the project bot closes issues it will (at least sometimes) cause the node to lose it's group association.

You can fix that problem running this query:

update og_ancestry oa inner join project_issues pi on oa.nid = pi.nid set oa.group_nid = pi.pid where oa.group_nid = 0;

I should say: that query fixes it in the short run, but is obviously not the long run solution.

I think that I take care of all of the issues raised here, including #32, in #1510146: Make og_project work with projects that are standard group posts. I have not tested with the project bot directly, though. Give the aforementioned patch a try; if it does solve all of the problems in this issue, then perhaps we can close this as a duplicate.

This issue is needs work, afaik. If it's a dup it's a dup. I'm no longer working on it though.