Engineering / ENG-1710
Vossberg depot import
Description
Shaped in Emargen: Vossberg depot import. Product page: Confluence PROD › Depot import.
Why
Vossberg has 60 depots and we have 41, made by hand since 2024, with codes that don't match the depot codes Okta sends. People at the 19 missing depots are homed at the nearest one, so their requests go to the wrong approvers and the Access report by depot is wrong for them (SUP-1107).
What we build
- Depots › Import in the portal: a CSV file, UTF-8, up to 500 depots. Columns: code, name, address, country, and optionally
replaces, the old code a depot replaces. - A dry run first: how many depots would be added and updated, and every problem.
- A depot is matched by its code, or by the old code in
replaces, and updated; otherwise added. Nothing is deleted.
Not in this epic
- Moving people to their new depots (the people import does that). Deleting depots.
Done when
Vossberg's file is loaded in production. Target 25 September.
Child issues
- ENG-1711 Depots › Import: CSV with code, name, address, country and replaces Done
- ENG-1712 Dry run: depots added and updated, and every problem Done
- ENG-1713 Run Vossberg's file on staging and check it against people's home depots Done
- ENG-1715 Depot import never touches a depot's single sign-on Done
- ENG-1732 Depot import accepts a file that isn't UTF-8 and mangles the names Done
Linked issues
- relates to SUP-1107 Vossberg: load all 60 depots from a file, with the codes Okta sends Done
- relates to SUP-1148 Vossberg: depot import file format Done
- relates to SUP-1171 Vossberg: depot import file rejected, umlauts broken Done
- relates to SUP-1190 Vossberg: depot import done, anything to watch before we re-home people? Done
Loaded in production today: 19 new, 41 updated, none removed. Bettina's people import moves people to their real depots on Monday. Closing.