Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kit redesign roadmap #3652

Open
dorner opened this issue Jun 11, 2023 · 6 comments
Open

Kit redesign roadmap #3652

dorner opened this issue Jun 11, 2023 · 6 comments
Labels
core team Groomed but likely needs expert knowledge stale

Comments

@dorner
Copy link
Collaborator

dorner commented Jun 11, 2023

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 dorner self-assigned this Jun 11, 2023
@dorner dorner added the core team Groomed but likely needs expert knowledge label Jun 11, 2023
@dorner
Copy link
Collaborator Author

dorner commented Jun 16, 2023

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
Copy link
Collaborator Author

dorner commented Jun 16, 2023

For discussion on Sunday.

@github-actions
Copy link
Contributor

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
Copy link
Contributor

github-actions bot commented Jul 2, 2023

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
Copy link
Contributor

github-actions bot commented Aug 7, 2023

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
Copy link
Contributor

Automatically unassigned after 7 days of inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core team Groomed but likely needs expert knowledge stale
Projects
None yet
Development

No branches or pull requests

1 participant