Feature request: add deactivation for repairs

[lauratomas]

There are two reasons why equipment is currently deactivated:

• repairs
• use by STC

If equipment is deactivated for repairs, the equipment item table within the equipment model view should mention this (and, if possible, display the SN incident number).

Another option is to allow admins to leave a deactivation reason that is then displayed in the equipment item table.

[austinczarnecki]

We're going to go with option 2 where admins can leave a deactivation reason. Ideally we should have some presets and an 'other' where you can fill in custom reasons. This is a place where the admin could leave the SN incident number.

[lauratomas]

Reason can be 50 characters max.

[shippy]

Proposed implementation steps:

Front-end:

• "Deactivate" button + deactivation reason display on an EquipmentObject index & show page
• table column deactivated? in EquipmentModel view, displaying deactivation reason

Back-end:

• EquipmentObject gets a new column deactivated? and deactivation_reason
• EquipmentObjectController gets new methods #deactivate and #reactivate
• Both get routes /equipment_object/:id/[dr]eactivate

[shippy]

@lauratomas Who should have the permissions to deactivate/reactivate equipment? Admins only, or checkout people as well?

[squidgetx]

best part of cancan, you just write something like if can? :deactivate, EquipmentObject and you're free to decide/change which role is allowed to do that whenever you want

Also, #547

[shippy]

@squidgetx: I know that :) I'm trying to figure out the 'later'.

As it turns out, scratch most of the above plan: this feature is partially implemented in application_controller.rb (by @austinczarnecki, best as I can tell from git blame). Methods .activate and .deactivate are inherited by all controllers, calling .destroy on the instance in question merely sets .deleted_at and freezes it, and calling .revive (which is a strangely undocumented core Ruby function) restores it.

The de/activation seems to be unrestricted if URL hacking, but the link is hidden in view for non-admins.

Consequently, what is missing from this feature is (a) CanCan-based restriction (b) the ability to set and display a deactivation reason. I'll focus on implementing the latter for EquipmentObjects, probably via a method override and calling super to be consistent.

[shippy]

Checklist for tomorrow:

• remove deactivated from EquipmentObject model (deleted_at is sufficient) and re-migrate
• alter deactivate and activate methods in EquipmentObject controller so that they call super and then re/set deactivation_reason
• enable the setting/display of deactivation_reason in view

[shippy]

Added a deactivation_reason input field to EquipmentObject edit view and an onclick event for the "Deactivate" button.

With regards to security, PUT means that neither De/activate button is easily hackable; CanCan should catch access to the respective methods.

All in all, I think we're good to go; filing a pull request.