fix: permission checks for updating or viewing projects in orgs

[shreddedbacon]

General Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for inclusion in changelog

Database Migrations

• If your PR contains a database migation, it MUST be the latest in date order alphabetically

The problem

Prior to organizations being introduced, users with update:project on projects had permission to add, edit, and delete DeployTargetConfigs on projects. The roles that allow this currently are maintainer and owner roles (and higher level roles).

After the organizations roll out, the update:project permission on the above interactions was changed (probably incorrectly) to only allow organization administrators with the updateProject:organization permission to make changes to these configs.

Other roles that allow update:project still permit users with this permission to perform the same changes they used to do. This includes directly modifying the project settings, adding/removing metadata, and also modifying an environment to use a different deploytarget directly.

This permission change is to still allow users that previously had the update:project permission to modify DeployTargetConfigs to perform these actions, while still allowing organization adminstrators the ability to do so.

Modifying DeployTargetConfigs of a project in an organization will still require the deploytargets to be available to the organization as before, there is no change to this behaviour.

Changes

• checkOrgProjectViewPermission
  • this is changed to check firstly if a user has the view:project permission, if not it will check if the project is in an organization or not and will then perform the organization check.
  • previous behaviour was to check organization permission, and then fall back to view:project
• checkOrgProjectUpdatePermission
  • this is changed to now check if a user has the update:project permission, if not it will check if the project is in an organization or not and will then perform the organization check.
  • previous behaviour was to check organization permission if in an org, but no fall back to update:project. It would only check update:project if the project was not in an organization.

[bomoko]

makes sense.