Closed orenyk closed 9 years ago
got the basics of this set up, although I don't like how we're butchering the make_deactivate_btn
method... maybe it's time to split it into different helpers? Alternatively, we could have the helpers inherit and write customizations there. I'll keep testing / looking into this.
Ok, so I moved the make_deactivate_btn
method into ApplicationController
and the various other controllers so we can use inheritance, but unfortunately it doesn't quite do what we need. Since the method functionality is based on the controller, each view's button is dependent on the controller that calls it. However, some views (for example equipment_model#show
) utilize buttons for different objects, hence the original disambiguation. As kludgey as it is, I think we might have to go back to keeping a single method in ApplicationHelper
with model-specific conditionals. I'm investigating.
In the process of setting that up, I encountered an error w/ the permanent_records
gem that we're using for soft deletion having to do with a deprecated ActiveRecord query (see the relevant PR). This hasn't been released as a specific version, so we should keep an eye out for future updates, but for now we're pointing at a specific commit.
Ok, I think this is good to go, and I'm happy w/ how we refactored our make_deactivate_btn
method using decorators (thanks @mnquintana!). Issuing PR!
Note that we also added the functionality where deactivation of a category or equipment model will archive all associated reservations (similar to #288).
Similar to #983 (inspired by discussion in #1037), we should ask for confirmation when deactivating equipment models that have either currently checked-out or future reservations within the next [week?]. This should probably be implemented for categories as well.