Rename the current models and roles to fit with the newly introduced ones
Request and Reimbursement are not enough anymore, since the plan is to support different kind of requests, reimbursements and similar processes. Request should become TravelRequest, and so on.
Same apply to roles, with more players coming into play.
#1 Updated by ancorgs almost 9 years ago
- Status changed from New to In Progress
Renaming Request to TravelRequest. Still a WIP (some pending issues with inherited resources and CanCanCan).
#2 Updated by ancorgs almost 9 years ago
Further analysis of the upcoming needs. Designing a slightly different approach that will allow to introduce the changes WE (in the team) need without such a big refactoring.
#3 Updated by ancorgs over 8 years ago
The current approach uses names for the models that suck but that have allowed us to move forward without needing too much refactoring:
- Request: Any request that needs a reimbursement (currently travel support, shortly also local reimbursement of merchandising).
- Reimbursement: Associated to a request of any type.
- Shipment: For the booth boxes, that doesn't need reimbursement.
But those convenient but counter-intuituve names should not be exposed in the interface. I18n files should be updated with proper names.
#4 Updated by ancorgs over 8 years ago
Changed the i18n to make the texts displayed to the user a little bit more intuitive. Quite some time adapting the tests.
#5 Updated by ancorgs over 8 years ago
Request will be renamed to TravelRequest. Shipment should probably be renamed to ShipmentRequest.
There will be no Request base class. The behaviour will be implemented including two concerns: HasStates and HasComments.
RequestExpense will be renamed to Expense and Reimbursement will remain as it is. Both will be reused for any kind of request that needs to go through a reimbursement process (not only TravelRequest). For sharing the Reimbursement and Expense associations there are two options:
- Implementing a Reimbursable concern and making the associations in Expense and Reimbursement polymorphic.
- Implementing a ReimbursableRequest base class with the associations, instead of a concern.
#6 Updated by ancorgs over 8 years ago
RequestExpense renamed to Expense and first steps implementing the first alternative described in the previous comment (using concerns and polymorphic associations).
#7 Updated by ancorgs over 8 years ago
Discarding the work done before (lesson learned: don't forget to use branches) and implementing the second alternative (with a Request base class for everything since it sounds more coherent).
#8 Updated by ancorgs over 8 years ago
- % Done changed from 0 to 20
Working on it. Renaming and reorganizing models in Rails is always a lot of work (specially with STI involved).
#9 Updated by ancorgs over 8 years ago
rake spec:models already working after the whole refactoring/renaming (and that's 623 checks).
#10 Updated by ancorgs over 8 years ago
- Status changed from In Progress to Closed
- % Done changed from 20 to 100
Now we have two abstract classes: Request and ReimbursableRequest.
Request becomes TravelSponsorship < ReimbursableRequest
Shipment becomes Shipment < Request
RequestExpense and Reimbursement are now attached to ReimbursableRequest instead of Request.
#11 Updated by ancorgs over 8 years ago
Some routes introduced for backwards compatibility. /requests and /requests/XX