Checkout Items Can't Be Deleted

[caseywatts]

We have lost the ability to remove equipment items. I'm not sure when this last worked, since it's used infrequently, but we noticed it since the last update to bmec reservations. If we don't have a test for this, we should.

To reproduce:

1. Go to an equipment model edit page
2. "remove" a checkout step
3. Save the changes
4. You're taken to the equipment model show page, but the removed checkout step remains.

(Austin, you can assign this to someone else - just letting you know it exists)

[orenyk]

Played around with this - I've verified the bug on the development branch and also found that it occurs with checkin procedures as well. Looking at the console it appears as though the deleted_at attribute of the specific checkout/checkin item is set to the time I clicked on the "Remove Step" button, but it's not actually deleting the record. I'm assuming this has something to do w/ the gem we're using for the forms, but I haven't quite figured out the underlying JS yet.

[orenyk]

Ok, here is an update:

1. The issue results from our use of the PermanentRecords gem and the fact that we're soft-deleting checkin and checkout procedures. Since destroy-ing the procedures only changes the deleted_at parameter of the records, they still show up as children of the active equipment models.
2. One solution is to add a helper / some code to the update method in the equipment_models_controller to search through the form parameters, find the checkin and/or checkout procedures that are marked for destruction, and hard delete them using destroy(:force).
3. This has been done and seems to work, but is messy and unfortunately has a lot of code duplication since we need to use different methods on @equipment_model to access checkout and checkin procedures separately, as well as different symbols to pull the relevant hash from the form params. Does anyone know how to symbolically change a method and/or symbol? In other words, if we need model_params[:checkout_procedures_attributes] and model_params[:checkin_procedures_attributes], how can we dynamically change the symbol? Similarly, if we need to call @equipment_model.checkout_procedures and @equipment_model.checkin_procedures, is there any way to dynamically change the method?
4. One alternative solution would be to stop using soft-delete for the checkout and checkin procedures since they have a many-to-one relationship with equipment models. If we soft-delete the equipment model, there's no reason why we need the procedures to be soft-deleted since they won't ever show up anywhere else. The only thing that needs to be checked is whether or not the procedures will be hard-deleted when we call destroy on the equipment model - this will require digging into the gem a little bit.

That's where we stand. TL;DR:

• the issue is that we're soft-deleting procedures
• we've fixed it but it's clunky
• looking for a way to dynamically define methods and symbols
• looking into the PermanentRecords gem to see if we need to be soft-deleting procedures

[orenyk]

Ok, I've used dynamically defined methods and symbols to put the fix in equipment_models_helper.rb so the code is a little cleaner. The fix is still a bit kludgy, though. I'm going to look into the PermanentRecords gem and see how it handles dependants.

[orenyk]

There was no good way to use the PermanentRecords behavior to fix this; removing the deleted_at field from the checkin_procedures and checkout_procedures models (and thereby bypassing the gem) causes issues with deactivation, so we're sticking with the kludgier solution. The helper function was moved to application_controller.rb and the code was commented / cleaned up, so it should be good to go after the next commit!

[orenyk]

As per Casey's request, moved the helper function to equipment_models_controller.rb (and had some silly git issues hence the numerous commits).

[orenyk]

Received feedback via our Google form:

can't remove steps from the canon rebel t3i's check out procedure

I believe we've already fixed this and merged with development, not sure if it's been pushed to production. I'll check to see which instance was being used and figure out if the fix has been deployed.

UPDATE: This was on the BMEC instance. It doesn't look like the fix was merged past development, checking with @caseywatts to see how to respond.

UPDATE 2: Confirmed with @caseywatts, fix has yet to be deployed. Updated the user, no need to re-open the issue.