"Edit" link in releases table is visible, but access denied

a) Please provide specific links to the release nodes in question.

b) Do you consistently get access denied for all release nodes you're trying to edit, or just a few?

c) You should be able to edit release nodes for that project now. If you can't, it might be a case of, for example, the input filter set to full HTML for some reason, which you don't have permission to use. That's actually a pain in the ass for project_release.module to get right with this feature of letting everyone with CVS access edit the release nodes. That feature depends on testing access based on the project, not the specific release node. Otherwise, there's no way to give you permission to edit release nodes created by Ber. But, since we're not testing access on the release node itself, if something other than the project ownership and CVS access was causing the access denied (input filter, etc), then project_release won't know, and will print the edit link anyway.

So, this is probably "by design", but I need more info before I can say for sure.

I posted a similar question here, but received no answer so far.

Turns out this is another bug introduced by http://drupal.org/node/151892. :(

When project_check_admin_access() was ported to use project_use_cvs(), we were passing in the $project variable which in some cases is just a nid, and in other cases a full project node object. We really need to use $project_obj, which is always the full node object. Attached patch solves it via local testing.

Same here. :-)

@hass -- if you know it's OT, then please file another issue.

@dww -- might be a good idea to move that object loading logic right into project_use_cvs(), which would make the function more flexible and prevent these problems going forward.

And, just to defend ourselves from future bugs of a similar nature, new patch that adds code to project_use_cvs() to handle either nids or full node objects. Since node_load() is caching everything, anyway, it doesn't really hurt.

@hass and goofyx: same bug.

looks good.

Committed to HEAD and DRUPAl-4-7--2. Installed on d.o.

Nice. Thank you guys!