Changes required for APIv3 in corporate #6489
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Move out the logic that authorize a user hitting /projects/ and create a different class for this (it's used in corporate as well). Leave the PublicDetailPrivateListing class only with the needed logic for this goal: detail access is public and listing access is private.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
humitos
added
PR: work in progress
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This is blocked. I'm waiting for organization being migrated to .org. |
…humitos/apiv3-corporate
- /organizations/: list all the organizations for the logged in user - /organizations/<organization-slug>/: details of organization - /organizations/<organization-slug/projects/: projects for the organization Note that these URLs are not enabled yet. They are registered in corporate for now until we enable organizations in community.
humitos
removed
PR: work in progress
|
I think this could be reviewed soon. I don't expect to too much big changes. |
By using `or` instead of `any` we return True immediately if the first condition is True without calling `PublicDetailPrivateListing`. This avoid generating 404 exception because there is not project found on /projects/ URL
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
humitos
added
Accepted
…humitos/apiv3-corporate
stsewd
reviewed
Oct 5, 2020
…humitos/apiv3-corporate
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes changes required in .org to make it possible to use APIv3 in corporate by extending some permission classes.
There main changes are:
PublicDetailPrivateListingpermission class: move out the logic that checks for a user accessing/projects/(without a project slug) to list all their projectsCommonPermissionsclass that can be overriden from corporate: we can't use theSettingsOverrideObjectpattern withAPIv3Settingsbecause view classes inherit from it and so, all the classes will have the_default_classand will be overriden.Organization(don't enable the URLs in community) and make them extendable from corporateI'm not super happy with 2) but I'm not sure what other pattern we can use to make it more extensible. With my proposal here, any change we need to do in
APIv3Settingsfor corporate will need another override or a setting or similar.