-
Notifications
You must be signed in to change notification settings - Fork 4
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
feat(Users): Add elife_author as custom attribute #855
base: master
Are you sure you want to change the base?
Conversation
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.
Thanks for adding this @nokome, I think for our purpose of presenting varying user documentation, the logic for including any user whose project includes an eLife source is unnecessary.
As an aside, and touching on the conversation we had earlier, I do still think a desirable longer-term solution would be to configure these from the database in order to keep these decoupled from the code and other open-source deployments.
# User is a member of at least one project that is (a) owned by eLife, or | ||
# (b) has an eLife source. | ||
elife_author = ( | ||
get_projects(user, include_public=False) | ||
.filter(Q(account__name="elife") | Q(sources__address__startswith="elife://")) | ||
.count() |
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.
I think for the purposes of user segmenting, the second scenario of any user with a project with an eLife source is an unnecessary criteria.
# User is a member of at least one project that is (a) owned by eLife, or | |
# (b) has an eLife source. | |
elife_author = ( | |
get_projects(user, include_public=False) | |
.filter(Q(account__name="elife") | Q(sources__address__startswith="elife://")) | |
.count() | |
# User is a member of at least one project that is (a) owned by eLife. | |
elife_author = ( | |
get_projects(user, include_public=False) | |
.filter(Q(account__name="elife")) | |
.count() |
project = Project.objects.create(account=self.ada.personal_account) | ||
ElifeSource.objects.create(project=project, article=1234) | ||
attrs = get_custom_attributes(self.ada) | ||
assert attrs["elife_author"] is 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.
Related to the above comment
assert attrs["elife_author"] is True | |
assert attrs["elife_author"] is False |
I think I'd prefer to go with the longer term option now, if possible. I now see UserFlow has the notions of {
"id": "e9b32bd0-63cb-415e-9c4f-477c85b92f97",
"object": "group_membership",
"attributes": {
"role": null, // User is not a member of the account
"on_project" // User is a member of at least one project owned by the account
},
"created_at": "2019-10-17T12:34:56.000+00:00",
"group_id": "ab82c312-b3a4-4feb-870c-53dd336f955e",
"user_id": "2a845972-4cde-4cb4-ba14-5cb2fc15ec4c"
} Please let me know, it that would suit your needs and what |
Yes, that would solve our needs perfectly and be even better ✨ |
Please see comments and tests for logic for true / false. Can be altered is necessary.