Kit redesign roadmap

[dorner]

Summary

Design and decide on an implementation roadmap for the kit redesign - #3562 .

Things to consider

Think about:

• Can we split up the work into multiple tickets?
• Can we minimize the disruption to the data?
• Can/Should we do things like strangler fig pattern, double writes, etc?

Criteria for Completion

[] Roadmap is recorded in this issue [] Roadmap is discussed with core team and any feedback is incorporated [] Resulting issues are created

[dorner]

Suggested roadmap strategy:

• The nice thing about kits is that they are currently a separate table besides items. Most of the information lives in Items, which is where we plan on it living long-term.
• Based on this, we can keep the "write to kits, sync to items" behavior along with our changes until we are confident that we can remove it. Updating kits already updates the associated item, so we are essentially just moving our "source of truth" from Kits to Items, without any loss of data.
• The main weirdness will be with line_items - we are moving the itemizable_id from a kit to an item. I think this should be a relatively benign change - since items have a 1:1 relationship with kits in this case, we aren't losing any data.

Suggested work items:

• Change itemizable_id source:

  • Add the Itemizable module to the base Item class.
  • Add a migration to change the itemizable_id for all kits' line items to instead point to the kit's item. Back up the DB first!
  • Update views and allocation / deallocation logic to work with the item's line items instead of the kits.

• Create new models:

  • Create new KitItem and ConcreteItem models, add the type field, copy code as needed and add associations as needed (line_items).
  • Add a migration to assign the type KitItem to all items that have a kit_id. The other columns should more or less line up and we shouldn't need to worry about changing them.

• Update view to use new models

  • Views should use KitItems instead of Items + Kits. Again, we can use the feature flag to key off how the views and any other code (e.g. parameters) look.
  • Simplify views to avoid checks on whether an item has a kit or not - in most cases we can either remove the check entirely, or we would want to change the check to whether the item has line items or not.

• General cleanup and code fixes

  • Go through the rest of the codebase and ensure that all code that's looking at kits is (feature-flagged to) look at KitItems instead.

• Release and monitor

• Put out the release. Monitor how the feature is used and if we see any errors. Revert if there are any. Put out fixes and repeat.

• Cleanup kits

  • Once we are satisfied that the release is successful, we can remove the old Kits and Item classes and any code on the "false" branch of the feature flag.
  • Stop writing to the Kits table.

• Clean up data

  • Drop the kits table and remove kit_id from Items.

• Future improvements

  • Create issues for future improvements - most importantly being able to see all line items in any item if it has them, on any page that displays items.

[dorner]

For discussion on Sunday.

[github-actions[bot]]

This issue has been inactive for 244 hours (10.17 days) and will be automatically unassigned after 116 more hours (4.83 days).

[github-actions[bot]]

This issue has been inactive for 364 hours (15.17 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.

[github-actions[bot]]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[github-actions[bot]]

Automatically unassigned after 7 days of inactivity.