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

Config options added to make EULA process more thorough #550

Open
wants to merge 39 commits into
base: main
Choose a base branch
from

Conversation

rg663
Copy link
Collaborator

@rg663 rg663 commented Jul 8, 2023

Resolves issue #542 — Now, centers who want to have a more thorough process for users on allocations whose resources have a 'eula' attribute can set the config variable EULA_AGREEMENT to True. With this, when a user is added to an allocation with a EULA resource, any user that is added (who is not an admin or a PI) has a status of Pending instead of Active. When this user goes to access the resource, they must either accept or decline the EULA. If they accept, they become an Active user on the allocation. However, if they decline, their status is set to Declined.

In addition, when a user is added to an allocation with a EULA resource, they receive an email asking them to complete the EULA. When a user agrees to the EULA, an email is sent to the user and their manager to confirm this process. If the config variable EMAIL_EULA_REMINDERS is set to True, users are emailed weekly to remind them to complete their EULA process.

@dsajdak dsajdak self-requested a review August 10, 2023 20:48
if EULA_AGREEMENT:
allocation_user_pending_status_choice = AllocationUserStatusChoice.objects.get(name='Pending')

allocation_user_status = get_object_or_404(AllocationUser, allocation=allocation_obj, user=self.request.user).status

Choose a reason for hiding this comment

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

This should check all users on an allocation and only show the ability to accept/deny EULA to the relevant user. As is, this breaks views where the user is not a member of the allocation (e.g. an admin/staff view looking to approve/deny the allocation)

@jrlagrone
Copy link

We're looking at making similar changes. I'll try to add fixes / updates as we get to them (no eta at this point.)

Right now, this PR is not completely functional (at least for us):

  • Views check the current user for EULA approval. This breaks admin/staff/etc views, where the admin/staff/etc is not a member of an allocation
  • Approving an allocation changes all users to "Approved" even if they haven't agreed to terms.

@jrlagrone jrlagrone mentioned this pull request May 10, 2024
8 tasks
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.

2 participants