Skip to content

Conversation

@NobodysNightmare
Copy link
Contributor

@NobodysNightmare NobodysNightmare commented Jan 19, 2026

Previously there was a separate permissions check for /api/v3/versions/:id. This check at least looked like it was inconsistent with the visible-scope.

Using the scope both for /api/v3/versions and /api/v3/versions/:id ensures that both will return results consistent with each other.

References

Discovered as a side-find while working on #21661

@NobodysNightmare NobodysNightmare requested review from a team and ulferts January 19, 2026 09:37
let(:portfolio) { create(:portfolio, public: false) }
let(:inaccessible_project) { create(:project, public: false) }
let(:version) { create(:version, project:, sharing: "system") }
let(:version) { create(:version, project:) }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this surprising. Why would a spec that's designed to show that something might be inaccessibile define the tested version to use sharing: "system", which means that the version is shared system-wide?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently because it was never checked in the API :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. That's what I am hoping for. The worse explanation is usually something like "it's intended, you just don't understand how/why".

But I agree, it probably just was never noticed.

@klaustopher
Copy link
Contributor

The old and the new check is not really equivalent. The authorize_in_projects checks that the user either has the view_work_packagespermission OR the manage_versions permission. The check in the visible scope only checks for view_work_packages.

I'm not too sure if it makes sense to have a user with manage_versions permission but not view_work_packages, but maybe we should extend the visible check to also allow those with the manage_versions permission

@NobodysNightmare
Copy link
Contributor Author

The old and the new check is not really equivalent.

Thanks for the feedback. Yes this is true, though looking at the failing specs I didn't expect it to be so bad xD

I'm not too sure if it makes sense to have a user with manage_versions permission but not view_work_packages

Me neither, but on the other hand we allow for this in our permissions scheme 🤷 And at least one spec relied on it.

@NobodysNightmare NobodysNightmare force-pushed the visibility-consistency branch 2 times, most recently from 763be76 to 863e3c1 Compare January 19, 2026 12:52
Previously there was a separate permissions check for
/api/v3/versions/:id. This check at least looked like it was
inconsistent with the visible-scope.

Using the scope both for /api/v3/versions and /api/v3/versions/:id
ensures that both will return results consistent with each other.

As part of this change, the manage_versions permission was also added into
the Version.visible scope and the Version#visible? method, because it was missing so far
from those places.
@NobodysNightmare NobodysNightmare merged commit 585f2f8 into dev Jan 19, 2026
16 of 17 checks passed
@NobodysNightmare NobodysNightmare deleted the visibility-consistency branch January 19, 2026 14:56
@github-actions github-actions bot locked and limited conversation to collaborators Jan 19, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants