Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix #1010 #2059

Merged
merged 7 commits into from
Feb 3, 2017
Merged

fix #1010 #2059

merged 7 commits into from
Feb 3, 2017

Conversation

antgonza
Copy link
Member

To solve this issue we can either do a complex SQL command or simply verify per filepath_id and return true/false. For simplicity and to keep a similar-to-previous/detailed-structure decided to go with the latter option.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 91.471% when pulling 7f97f2a on antgonza:fix-1010 into 15fcceb on biocore:master.

Copy link
Contributor

@josenavas josenavas left a comment

Choose a reason for hiding this comment

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

@antgonza I really like the approach that you propose here and I think it can be improved a bit better. Basically the problem before is that this function was really expensive, and this one is still expensive since it is still doing a search over all files available in the system (in the worst case scenario) to decide if the user has access to the file or not.

I think since you already have the filepath id, you can backtrack what the filepath is and check if the user has access or not. This will reduce the time complexity of this function from O(func(N)) (func(N) is actually pretty complex, hence just putting func(N)) to O(1).

I think the better approach is ask where the file is attached to and then check access for that object:

  1. Is this an artifact file?
  2. Is this a prep template file?
  3. Is this a sample template file?
  4. Is this an analysis file?

With just asking those 4 questions (using SQL) you just need to ask 1 or 2 more things to decide if the user has access or not to the file.

Does it make sense?

@@ -48,7 +47,7 @@ def _get_data_fpids(constructor, object_id):
return {fpid for fpid, _, _ in obj.get_filepaths()}


def get_accessible_filepath_ids(user):
def validate_filepath_access_by_user(user, filepath_id):
"""Gets all filepaths that this user should have access to
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you update the one sentence description of the documentation?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 91.473% when pulling 23104d7 on antgonza:fix-1010 into 15fcceb on biocore:master.

@antgonza antgonza mentioned this pull request Jan 29, 2017
2 tasks
# artifacts
if arid:
# check the public artifacts
public_artifacts = qdb.artifact.Artifact.iter_public()
Copy link
Contributor

Choose a reason for hiding this comment

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

I think I have not explained myself correctly on the previous comments. As it is currently written here, you're still iterating over all the artifacts. However, at this point you can now which artifacts this have been seen:

sql = """SELECT artifact_id FROM qiita.artifact_filepath WHERE filepath_id = %s"""

Similarly you can do for the other entries. You may be able to modify the above call to return the values in an array so you already have them.

@@ -11,7 +11,7 @@ INSERT INTO qiita.qiita_user (email, user_level_id, password, name,
'$2a$12$gnUi8Qg.0tvW243v889BhOBhWLIHyIJjjgaG6dxuRJkUM8nXG9Efe', 'Dude',
'Nowhere University', '123 fake st, Apt 0, Faketown, CO 80302',
'111-222-3344'),
('shared@foo.bar', 3,
('shared@foo.bar', 4,
Copy link
Member Author

Choose a reason for hiding this comment

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

level 3 is superuser and 4 is use, shared user should be regular user so we can actually test that sharing/etc works ... let's see which other tests will fail ...

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.02%) to 91.525% when pulling 661342f on antgonza:fix-1010 into 4e380e0 on biocore:master.

@antgonza
Copy link
Member Author

antgonza commented Feb 2, 2017

Ready for another review.

Copy link
Contributor

@josenavas josenavas left a comment

Choose a reason for hiding this comment

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

2 quick changes - thanks @antgonza this looks way more efficient 😄

if (a.visibility == 'public' or a.study.has_access(user)):
return True
else:
for c in a.children:
Copy link
Contributor

Choose a reason for hiding this comment

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

for c in a.descendants.nodes():

children is only checking at the immediate children but not to the entire descendants.

@@ -0,0 +1,15 @@
-- Feb 1, 2017
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove this file as I don't think it belongs to this PR.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.03%) to 91.515% when pulling fcd249b on antgonza:fix-1010 into 4e380e0 on biocore:master.

@wasade
Copy link
Contributor

wasade commented Feb 3, 2017

nothing stood out to me, 👍

@josenavas josenavas merged commit 33bcbe5 into qiita-spots:master Feb 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants