Repository navigation
Conversation
|
Needs test. |
|
Looks as if we won't implement this, at least not in this way. close? |
|
I vote we leave it open / in draft until an alternative implementation presents itself. Is there a reason you want to close this? |
No reason. I think we decided it's best implemented as a specific query. |
|
We need to do more investigative work for #561. Let's keep this in draft for now. We can circle back once the 3.0.0 milestone is complete. |
|
Hm. Looks like I force-pushed over the old branch. Note for the future, don't do that. (Look for pre-existence of the branch name in GitHub. Duh.) Well, luckily I am very confident of the new code being better.... |
d-w-moore
changed the title
|
Will mark ready for review once I've run the tests through with rudra's changes included |
A query is done to determine the highest permission level the given user (or group) has on the target collection/data_object. A specific query will be used if the calling user has the availability, otherwise a reasonably efficient general query is used instead.
| # Find out if the query is already registered. | ||
| try: | ||
| specific_query = SpecificQuery(ses, alias='findQueryByAlias', args=('getMaximumPermissionForPath',)) | ||
| specific_query.execute() | ||
| except CAT_NO_ROWS_FOUND: | ||
| specific_query = None | ||
| else: | ||
| specific_query = SpecificQuery(ses, alias='getUserAccessType', args=specific_query_args) | ||
|
|
||
| # If there is no canned query available, and we are a rodsadmin, then install our own: | ||
| if not specific_query and ses.users.get(ses.username).type == 'rodsadmin': | ||
| specific_query = UserAccessTypeQuery(ses, args=specific_query_args) |
There was a problem hiding this comment.
Auto-installing a specific query is not how we've done things in the past.
We should just try to use it and if it's there, we're good. If not, use the fallback implementation. No need to test for existence.
There was a problem hiding this comment.
but this is better for testing, in the mean time, so it might be better to leave it there until an iRODS release containing the new specific query.
There was a problem hiding this comment.
If it's for test purposes, have the test explicitly add/remove the SpecificQuery. It's fine if the test tests for existence of the SpecificQuery before adding/removing it.
There was a problem hiding this comment.
This is done now! Just need to run through the test to check. Will do this before monday morning.
| coll=None, | ||
| data=None, |
There was a problem hiding this comment.
Consider using more letters for the parameter names.
coll is pretty obvious, but data isn't.
|
Cleaned up a bit. Will test soon. Hold off from further review until tests are passing. |
Check if the
usernamed (may be a user or group) has privilege at or above the givenaccess_levelto the collection or data object named bypath