-
Notifications
You must be signed in to change notification settings - Fork 333
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
[ENG-6668] Add Contributor Page Improvements for Institutional Access #10825
base: feature/institutional_access
Are you sure you want to change the base?
Conversation
e61b288
to
e532dae
Compare
@@ -1079,7 +1079,13 @@ def set_visible(self, user, visible, log=True, auth=None, save=False): | |||
if not self.is_contributor(user): | |||
raise ValueError(f'User {user} not in contributors') | |||
if visible and not Contributor.objects.filter(node=self, user=user, visible=True).exists(): | |||
Contributor.objects.filter(node=self, user=user, visible=False).update(visible=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overwriting save
doesn't always cut it, but this looks like that only place we .update
visibility, arguably we want to retain the ability to change the visibility which leans away from placing in DB constraints. However I think this is all visibility updates in the existing code.
456fde5
to
9c307a7
Compare
adcdd3f
to
70f2629
Compare
70f2629
to
9bd37a2
Compare
56f0959
to
9a72225
Compare
cd1629d
to
2ea118e
Compare
…or.mako and make boolean is_curator field
2ea118e
to
4e507b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments and questions.
…methods and add disabled checkboxes to UI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One tiny thing, and then one more check to see if we're using the right information for making UI decisions.
website/profile/utils.py
Outdated
@@ -33,6 +33,8 @@ def serialize_user(user, node=None, admin=False, full=False, is_profile=False, i | |||
'surname': user.family_name, | |||
'fullname': fullname, | |||
'shortname': fullname if len(fullname) < 50 else fullname[:23] + '...' + fullname[-23:], | |||
'is_institutional_admin': user.is_institutional_admin(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this for this view? It looks like it's being used, but is it being used properly? See below for more.
website/project/views/contributor.py
Outdated
@@ -287,6 +288,13 @@ def project_manage_contributors(auth, node, **kwargs): | |||
node.manage_contributors(contributors, auth=auth, save=True) | |||
except (ValueError, NodeStateError) as error: | |||
raise HTTPError(http_status.HTTP_400_BAD_REQUEST, data={'message_long': error.args[0]}) | |||
except IntegrityError as error: | |||
status.push_status_message( | |||
'You can not make an institutional admin a bibliographic contributor.', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'You can not make an institutional admin a bibliographic contributor.', | |
'You can not make an institutional curator a bibliographic contributor.', |
@@ -366,11 +406,26 @@ | |||
<td> | |||
<div class="header" data-bind="visible: accessRequest.expanded() && $root.collapsed()"></div> | |||
<div class="td-content" data-bind="visible: !$root.collapsed() || accessRequest.expanded()"> | |||
<div data-bind="ifnot: accessRequest.user.is_institutional_admin"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct, or is it that the request was made from the institutional dashboard? Does the request need to store this info, rather than inferring it from the institutional admin status? This goes back to not wanting all institutional admins to be automatically classified as a curator request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you are correct, I checked with Product again and they confirmed. This should ensure the user actually has made a pending institutional access request, not a normal access request.
f7dfae4
to
8ef8cd6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there. One optimization left.
osf/models/user.py
Outdated
return NodeRequest.objects.filter( | ||
request_type=NodeRequestTypes.INSTITUTIONAL_REQUEST.value, | ||
target=node, | ||
creator=self, | ||
).exists() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be sure, is there any place we can cache this info, such as a request object, rather than relying on this query, the same way we did with caching on the contributor object if it's a curator? Same reason as before, to avoid making this query for every contributor that gets serialized.
@@ -406,23 +405,23 @@ | |||
<td> | |||
<div class="header" data-bind="visible: accessRequest.expanded() && $root.collapsed()"></div> | |||
<div class="td-content" data-bind="visible: !$root.collapsed() || accessRequest.expanded()"> | |||
<div data-bind="ifnot: accessRequest.user.is_institutional_admin"> | |||
<div data-bind="ifnot: accessRequest.user.has_institutional_request"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here, for example, could be accessRequest.is_curator
or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still a bit more. What you did was not what I was asking for.
osf/models/contributor.py
Outdated
""" | ||
Checks if user a has requested a node using the institutional access request feature. | ||
""" | ||
return self.user.has_institutional_request(self.node) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still going to make the query once per contributor when loading the page. Could we make a boolean field on the NodeRequest
(or maybe AbstractRequest
, if we want to plan for the future) model to hold this information?
…ializing more directly from the objects to the template
0dc2738
to
0da606a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 🐧 🎉
Well, except for the failing tests. |
Purpose
The new Institutional Access feature creates a new "Curator" role that has certain requirements. The first is that it have a special label in the contributor list, shown here:
The second requirement is that the user is unable to set the curator to a bibliographic or "visible contributor.
Changes
QA Notes
What are the areas of risk?
Any concerns/considerations/questions that development raised?
Documentation
Side Effects
Ticket
https://openscience.atlassian.net/browse/ENG-6670