Ability to re-send EULA acceptance emails to everyone after EULA change

[snipe]

I'm splitting this discussion off from #11501 which was closed a while back but got frankenthreaded by @thetechjester (and I think it's a worthy thing to explore again.) @uberbrady and I have spent the afternoon kicking this around and thinking through how this would work, and the best approaches, both technically and user experience-wise.

This is an invitation to anyone interested in this feature to share their use-cases so we can refine what would meet the most users' needs and make sure the technical side of things covers as many bases as we can. Please do give us your use-cases for this feature (if you have any) in the comments.

We already have the ability to resend unaccepted asset emails via the unaccepted asset report, but this request is a little different in that the use-case here is that the EULA:

1. Has changed due to new policies
2. Didn't require sign-off before but now it does

What currently happens when an asset belonging to a category that requires acceptance (or if the general setting is that it requires acceptance) with or without a EULA is:

1. A checkout record is created in the action_logs table
2. A record gets created in the checkout_acceptance table gets created with null for accepted_at and declined_at

When a user accepts or declines an asset:

1. A new record gets created in action_logs with the action_type of accepted or declined
2. The existing record in checkout_acceptances gets updated with an accept/decline date, the EULA that was active AT THAT MOMENT gets stored in a column on that table, a PDF gets created that gets stored on the server (that also contains the EULA, if there is a EULA)

So how do we get there? (this is mostly ad-hoc notes - will be refined over time)

Bulk edit menu to resend unaccepted assets would.... ?

1. Add a new record to checkout_acceptances and then follow the same rules?
2. ???
3. Profile

Challenges:

1. If we do this at the category level as a bulk action, it will (as of now) send a new email for every single thing that a user might have checked out. It also seems like it might cover the most bases though, since it's possible that ONLY the EULA/acceptance policy of a single category has changed
2. If we do this at the user level, they will still (as of now) still get a new email for every thing they currently have checked out - same as above, and not awesome
3. Technical Implementation: if the policy has changed, for example you didn't used to have a EULA, the EULA has changed, OR you didn't used to require signatures and you now do, but you have 10k assets that were assigned before that change, they will not have records in the checkout_acceptances table, since there was no need for those records at that time.

Multiple Emails Problem - like the three body problem, but dumber

This gets tricky, since it's possible that the entire organization has changed their global EULA (assuming they're not using category-level EULAs) but it's also possible that an organization has changed each and every EULA for every category they have. From a UI perspective, this is lovecraftian.

If users were presented one page of things they need to accept, that's not difficult - BUT if there are 20 different EULAs they have to sign, one for each different category, that's just awful. (Putting aside the fact that we still want to offer acceptance for users that do not have the ability to login - whole other nut to crack.)

[snipe]

We probably need to modify the checkout_acceptances table to tie it to specific action_logs records. This could potentially be a chonky-boi query, but we'd only need to run it once, and then modify the code moving forward during those events.

[uberbrady]

Also - if anyone has any specific use-cases - not theoretical, but actual ones that come up in real life for you, for now - please share those with us to help us shape how this might work.

[ctsamuraix]

I think this sounds like something I'd like. Being able to send a reminder email if they haven't signed an item out(missed the original email/forgot/temporary issues with email config and weren't sure if the original email went out/etc)

[snipe]

@ctsamuraix we already have that functionality via the unaccepted asset report. This is a different use case (though your use case would also be covered here, in all likelihood.)

[ctsamuraix]

@ctsamuraix we already have that functionality via the unaccepted asset report. This is a different use case (though your use case would also be covered here, in all likelihood.)

oh damn, hadn't noticed that one before. thanks!

[uberbrady]

Here's my thoughts on how we might approach this -

1. Add a denormed 'eula_checksum' field to Assets to store the hash of the raw-text of the EULA that the user signed. Probably doesn't have to be cryptographically secure or anything, but we might as well? Depends on what we can index easily (see point 2, below).
2. Put an index across that so we can quickly check if something is or is not signed. The logic can get hairier here since different categories can have different EULA's or maybe the default EULA. So this might want to be a multi-column index across I guess model_id as well (which is where we set categories?)
3. Make a migration to go through every accepted asset and set the appropriate checksum (UGH!)
4. Modify the checkin method to blank out the EULA checksum.
5. Modify the acceptance method to set the EULA checksum.

Now, if the EULA changes, the expected checksum changes. so we would be able to see that the user signed an outdated EULA (or, when it's null - that they never signed any EULA at all).

Now we end up with some open questions as to whether you want to modify the unaccepted assets report to follow the new EULA checksum logic, or if we need a new report, or if we do this at the category level, or if we do it as a big Artisan command.......