Added #8414 - acceptance sign in place

[snipe]

Okay, this definitely needs some additional testing, but this should introduce the ability to check a checkbox on the checkout screen which adds in an interstitial that lets the user sign during the checkout process.

I had initially written this so that the full acceptance attribution would go to the signing user, but I decided that having the admin be the "actor" here with the target being the signing user and the item being the thing they're signing for kinda makes more sense, since you'll know that was an in-place acceptance/signing, but the EULA still shows up under the users' EULAs - and because it still ties it back to the admin who allowed the sign in place, so there's still accountability if an admin is trying to get froggy.

If you do check the "sign in place" checkbox, it will remember the state. I chose this because if your workflow tends to need sign-in-place, you probably want that most of the time, and it would be tedious and error prone to have to check that box every time.

It will also remember the state of the redirect you've picked in the actual "Go to" dropdown next to the checkout save button, so that after the item has been accepted or rejected, you still continue on to the final destination you wanted to be in.

It will also skip the "You have been assigned an item" email, since they're standing right there and they know they've been assigned a thing.

This will require some pretty extensive testing, but I think this gets us pretty close to the original ask.

There's some dumb variable stuff that PHPstorm encouraged me to do that I don't love but kinda didn't want to fight with my IDE about. ($currentUser always being auth()->user() seemed like it made it extraneous to be, but PHPStorm insisted it was because of type enforcement. Sure, okay. Fine.)

Things to Test

• Do checkouts work normally if you you don't check that box?
• If you do check that box, does it actually bring you to the signature page?
• If it does, and you sign it ("the receiving user signs it"), does it get logged correctly and does it redirect you properly?
• If you decline it, does it behave the same way declined acceptances work?
• When you check out another item of the same type, is that "sign in place" checkbox checked by default?
• When you look at the asset/license/whatever, do you see that acceptance in both the item history and the EULAS (where applicable)
• When you login as the user who the item was checked out to, do you see the signed EULA PDF?
• If you choose to sign in place, the signing user should receive ONLY the acceptance PDF email (if they checked the box to receive one). They already know they're being assigned the thing - they were right there.
• These above tests should be repeated for all affected item types (licenses, consumables, assets, accessories)
• If you reload that acceptance page, the flash of "Item checked out successfully" should disappear, but does it still work as outlined above?

Fixes #8414 and #3750

[codacy-production]

Not up to standards ⛔

🔴 Issues 1 medium

Alerts:
⚠ 1 issue (≤ 0 issues of at least minor severity)

Results:
1 new issue

Category	Results
Complexity	1 medium

View in Codacy

🟢 Metrics 32 complexity · 0 duplication

Metric	Results
Complexity	32
Duplication	0

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[marcusmoore]

I did some brief testing so far and it works as expected (more testing to do).

Only quickly scanned the changes but is the only signal that an acceptance was "sign in place" that the action log shows the actor is the admin and the target is the user? I feel like we should note that in the database. We've been bit in the past where we want to implement a feature but are missing some data from the past that would make it 100% easier to do.

[bzeus]

working on it

[bzeus]

still working on it, still have to go through some of the other items than assets, but looks good so far ...back at it in the am

[snipe]

@marcusmoore I think I mentioned that in the PR description (novel that it was). I don’t mind it only because it makes it clear that it was a sign in place, and perhaps more importantly, which admin used it. The acceptance itself is a separate action log entry, so the admin being the one who did it seems kind of okay? I’m definitely willing to argue about that tho. I went back and forth, so I can easily be convinced that I’m wrong.

[snipe]

One thing I noticed here - we have a requireAcceptance() method on the checkout able items, which checks at the category level, but we also have require_acceptance on the superadmin settings level. I feel like this is kind of confusing, and I honestly just don't remember why we set it up that way. Might have just been an oversight, but I think it gets confusing on the category edit page, since it makes it look like you have a choice there, even when it's set in the admin settings, so the acceptance will be required regardless of that checkbox.

Part of me wonders if we should just remove that from the admin settings. :-/

[snipe]

Okay, now I'm confusing myself lol

We kind of have 3 different levels of "acceptance". I think the "Require signature" one in admin settings means you have to actually sign for the thing, versus just accepting the EULA without a signature. Whew.

[bzeus]

I've tested all the possibilities you had in the description, everything looks like it is working as intended

I thought I had put my comment in last night already, I finished it yesterday