Fix the missing 'Edit Releases' tab for projects

[ghost]

If there are issues with the automated GitHub webhook that creates project releases on B.org, you can manually change release's 'supported' status, and change the 'recommended' branch. However the page where you can do this (https://backdropcms.org/node/[NID]/edit/releases) doesn't have a tab to access it (i.e you need to know and manually enter the URL).

Let's fix this so the tab appears properly.

---

Original post:

From Gitter:

BWPanda:
I have two branches for my module (1.x & 2.x), and even though the 2.x branch is set as default (in Github), it still lists the latest 1.x release as the latest: https://github.com/backdrop-contrib/back_to_top/releases
How do I make it show the latest 2.x release as the latest? This also affects downloading via Drush...

klonos
I did notice that problem when I was creating the security releases for that module, but there is no way to set a recommended release or release branch in b.org at the moment (nor to mark a release/branch as unsupported for that matter). Can you please file an issue for that?

[jackaponte]

I support this feature request!

In the meantime, should we provide some documentation somewhere for contributors to help them understand how releases get marked as "recommended" and how to fix it if it doesn't happen automatically?

[jackaponte]

Actually, this can be done, but maybe requires special permissions or special sleuthing skills to figure out how?

For https://backdropcms.org/project/webform_civicrm, I was able to manually navigate to https://backdropcms.org/node/1397/edit/releases, which is not actually represented as a tab in the UI. There I could set the "Recommended major version," which then fixed both the recommended version and the latest update date on the project page itself.

So perhaps the real need here is making that node/*/edit/releases page more visible, accessible, and easier for module maintainers to understand?

[jackaponte]

Many thanks to @herbdool for explaining how to fix this in #468! (And for also creating an issue about what I think is the same problem in #474)

[ghost]

I cannot figure this one out... I've made sure my local site is all up-to-date with the current B.org site. When I login as user 1, I can see the secondary menu with the Releases tab (see screenshot), but when I login as my own account (which has the Developer role), I can't see the secondary menu.

There are no permissions I'm missing that would display this, and I can't find any code that would hide this. Help?

[herbdool]

Darn, I thought you had a fix. Perhaps somewhere it's checking for user 1, not permissions?

[ghost]

Ok, so I've found the issue. It's with Project module...

It has this code:

function project_menu_alter(&$callbacks) {
  $callbacks['node/%node/edit/project'] = $callbacks['node/%node/edit'];
  $callbacks['node/%node/edit/project']['type'] = MENU_DEFAULT_LOCAL_TASK;
  $callbacks['node/%node/edit/project']['title'] = 'Project';
  // Only take over secondary local tasks for projects.
  $callbacks['node/%node/edit/project']['access callback'] = 'project_user_access';
  $callbacks['node/%node/edit/project']['access arguments'] = array(1, 'edit project');
}

This changes the access callback for node/%node/edit/project, which apparently affects node/%node/edit/releases too.

project_user_access() then has 3 ways in which you're granted access:

1. If you have the 'administer projects' permission (which it turns out doesn't exist, so that fails for everyone except user 1 (since user_access() grants user 1 access to all permissions, even if it doesn't exist))
2. If you're the author of the project node
3. If you're listed as a maintainer with the appropriate permission (but this 'maintainers' list also doesn't exist)

So that's why user 1 gets access, and why no one else (other than the node author) does.

The solution here is either to fix the Project module, or bypass it in order to grant more people access to the Releases tab. Ping @quicksketch 🙏

[jenlampton]

I've filed a PR against project that adds back the missing hook_permission() that may be enough to move this issue forward.

[herbdool]

@jenlampton do you have a link to the PR?

[jenlampton]

Yes, that would be helpful wouldn't it :)
backdrop-contrib/project#44

[ghost]

I've filed a PR against project that adds back the missing hook_permission() that may be enough to move this issue forward.

It seems so. I confirmed that I couldn't access the Releases sub-tab on my local when logged in using my own account (i.e. not user 1). I then patched the Project module with @jenlampton's PR and it added new permissions. After assigning the 'Administer projects' permission to the Developer role, I was able to see and access the Releases sub-tab.

So I guess once there's a new release of the Project module we can make a PR here that updates the module and adds that permission for developers.

[klonos]

Any update on this?

[jenlampton]

Has this patch not been applied to b.org? Oh jeez, sorry. Adding now...

[jenlampton]

patch applied, tested, and deployed. Sorry for the delay everyone, for some reason my brain stopped at making the patch. Usually I make the patch while documenting it in the project that needs it, so IDK why that part got skipped this time!