@feedmepos/mf-menu 0.32.75 → 0.32.77

package/dist/app.js

@@ -1,4 +1,4 @@
-import { F as e, i as r, j as o, o as t, r as i, u as p } from "./app-DE92r95F.js";
+import { F as e, i as r, j as o, o as t, r as i, u as p } from "./app-jJLYblaN.js";
 export {
   e as FmApp,
   r as i18nMessages,

package/dist/apps/mf-menu/src/helper/itemCategories.d.ts

@@ -20,23 +20,57 @@ export declare function getItemCategoryNames(categories: CategorizedItem[], item
  */
 export declare function getItemPositionFnByCurrentCategory(currentCategoryId: string | null): (item: FdoMenuV4Item) => number | null;
 /**
- * Position for a newly created item: strictly below every existing one, so the item sorts
- * to the TOP of whichever category it lands in.
+ * Position for a newly created item: its slot within the category it lands in, one past the
+ * highest already taken there, so items keep the order they were keyed in.
  *
- * Landing it last is unreachable. Every sort in the stack — `sortPosition` here, Dart
- * `sortByPositionCodeName` inside `overrideMenu`, and its Go port — appends the items whose
- * position is null AFTER all positioned ones, so no number can outrank a null, and most
- * items in a real menu carry no position at all. Sorting first IS reachable, so that is the
- * guarantee we make instead.
+ * The incremental counterpart of `withSheetOrderPosition`, which applies the same rule to a whole
+ * imported sheet. Both mean "the item's slot in this category", and a drag normalising a category
+ * to 1..n means the same thing, so all three paths write the same kind of number.
  *
- * Distinct descending values rather than a shared constant: the Dart sort behind the POS is
- * not stable, so items sharing a position have no defined order there.
+ * `max + 1`, not `items.length + 1`. Length breaks as soon as anything is deleted — positions
+ * 1,2,3 minus the middle one leaves 1,3 with a length of 2, and the next item would be handed 3
+ * and tie with the survivor. Tied positions have no defined order (the Dart sort behind the POS
+ * is not stable), so the new item could appear either side of it. Taking the max cannot collide.
  *
- * Negative values are safe end to end — `position` is an `optional double` in the entity
- * proto, the zod schema has no lower bound, and every sort compares it as a signed number.
- * A drag re-normalizes the affected category to 1..n, so the negatives are transient.
+ * Scoped to one category, because an item holds a separate position per category it belongs to —
+ * `item.position` for its main one, an `additionalCategories` entry for each of the rest. A max
+ * taken across the whole menu would still sort correctly but would drift away from the 1..n a
+ * drag writes.
+ *
+ * A null position means "never placed", so it does not contribute to the max. Those items sort
+ * AFTER every positioned one — `sortPosition` here, Dart `sortByPositionCodeName` inside
+ * `overrideMenu`, and its Go port all agree — so no number can rank a new item below them. New
+ * items therefore group above the never-placed ones, in the order they were entered. Landing
+ * them at the true end of a legacy category would mean renumbering it first; that is what a drag
+ * is for, and doing it on every add was rejected on ITS-000651 because a single addition to a
+ * long menu would then vanish off the bottom of the screen.
+ */
+export declare function getNewItemPosition(items: FdoMenuV4Item[], categoryId: string | null): number;
+/**
+ * Positions for an imported row: one slot in every category the item belongs to.
+ *
+ * The batch counterpart of `getNewItemPosition` — same rule, applied to a whole sheet at once
+ * instead of one item at a time, so the two agree on what a position means and manual additions
+ * carry straight on from where an import left off.
+ *
+ * Import is a full replace of the item module, not a merge: `MenuImport.deleteItem` drops every
+ * existing item whose `_id` is absent from the sheet. So the sheet row order is the intended
+ * order for rows that update an existing item just as much as for rows that create one, and a
+ * dense 1..n per category is safe — there is no unlisted item left behind to collide with.
+ *
+ * Every membership draws its own number, main and secondary alike. Stamping the main category's
+ * number onto each `additionalCategories` entry would tie with whichever item actually holds that
+ * number in the secondary category, and tied positions have no defined order (the Dart sort
+ * behind the POS is not stable). The sheet carries no column saying where an item should sit in a
+ * secondary category, so those memberships fall in the row order of the items that hold them.
+ *
+ * `takeNextPosition` hands out the next free slot in a category and is expected to have side
+ * effects — it is called once per membership, and the call order fixes the numbering.
+ *
+ * A useful side effect of all this: after any import every item in the sheet carries a position,
+ * so `getNewItemPosition` has a real max to build on rather than a category full of nulls.
  */
-export declare function getNewItemPosition(items: FdoMenuV4Item[]): number;
+export declare function withSheetOrderPositions<T extends Pick<FdoMenuV4Item, "category" | "position" | "additionalCategories">>(item: T, takeNextPosition: (categoryId: string | null) => number): T;
 export declare function getUpdatedItemsWithNewPositions(items: FdoMenuV4Item[], currentCategoryId: string | null): ({
     position: number;
     _id: string;