Update equipment deactivation popup

[orenyk]

I was just messing w/ the 3.3.x test instance and noticed that when we deactivate an equipment item it warns us that we'll be permanently deleting any associated reservations. Is this actually the case? From personal testing I don't think it is (and it shouldn't be), so we should change the message on that popup.

[squidgetx]

That is the current behavior

[orenyk]

I don't think that's true. I was on the BMEC dev instance, created / checked out / checked in a reservation for a specific equipment item, and then deactivated the equipment item. The reservation was still in the list of reservations, which is what we want. We shouldn't be deleting reservation history when we deactivate equipment.

[squidgetx]

Oh wait, the reservation had just moved to a different tab.

My bad.

[orenyk]

What tab did it move to?

[squidgetx]

It moved to the checked out tab, where it should've been. I'm just bad at using our own application ::

Anyway, it looks like the current activate and deactivate logic is sitting in the Application Controller in an attempt to generalize it to Categories, EMs, and EOs. When deactivating EMs all associated reservations are deleted (not deactivated), and when deactivating Categories all associated EMs are deactivated (and all of their reservations are deleted). So I guess this leads to a couple questions.

• Should reservations be deleted with Categories/EMs are deleted?
• And should we just distribute activate and deactivate logic among the controllers instead of putting it in the applicationcontroller? This will allow for more specific popup information as well as reducing the complexity of the code. EOs already have deac/activate methods that extend the application controller and Users straight up override the behavior.

[orenyk]

I think that we should never delete reservations, that history is pretty crucial to the operation of any lending service. In terms of the activation/deactivation logic, let's definitely move it to the different controllers, and let's clean up the popup / flash messages as well.

[squidgetx]

Cool, I'm on it.

[squidgetx]

I'm actually no longer so sure about moving everything to the separate controllers. We would also have to add about 6 more routes as well as breaking the make_activate_btn logic as well.