Make a partly-undone import retryable, and refuse a plan it cannot deliver

Five findings from the review of the WINC import, plus the rendering each fix
needed to be usable.

An undo that hit a conflict wrote status 'undone' anyway, and undo_batch returns
immediately for an undone batch. So the one entry that needed a retry was the
only one that could never get it: the human resolves the conflict, clicks Undo,
and gets a no-op. A conflicted undo is now 'partially-undone', undoneat is
stamped only when the batch is genuinely finished, and the batches table offers
"Retry undo" for that status. The column was String(16) and the new value is
exactly 16 characters, so migration 7d38 widens it to 32 rather than rely on an
exact fit.

_UNDO_REFERENCES listed only assets, so a business unit this batch created was
hard-deleted even when something else still pointed at it. Two of the three
missing referrers are real FKs (dashboarddefaults.businessunitid,
businessunits.parentid): MySQL raises and the whole undo rolls back, so the
batch cannot be undone at all. The third, notifications.businessunitid, has no
FK, so the delete succeeded and left a notification pointing at an id that no
longer exists - silently, on both engines. All four are listed and the guard is
tested through the route.

The reference guard also queried tables that need not exist. A lean site drops
the tables of plugins it does not install (ADR-014), and notifications is
plugin-owned, so on such a site the query raised 1146, rolled the undo back and
left the batch permanently un-undoable. Absent tables are skipped; a table that
does not exist cannot hold a reference.

_PACKET_GROUPS reports on location, but apply_plan only ever creates business
units - it sets locationid only when the location already resolved. A plan
needing a new location asked the admin to acknowledge it, got the tick, wrote
nothing, and reported nothing. build_packet now takes the groups the writer can
actually create; anything else needed is 'uncreatable' and blocks at plan time,
where the admin can act on it, rather than dying at commit on a message about
acknowledging something the screen had no control for. The writer refuses the
same case independently. Both the console packet and the import page name the
blocking groups: setting blocking without printing the reason would leave the
banner pointing at nothing.

The web undo route caught ValueError only, so refusing a batch belonging to
another importer surfaced as a 500. That refusal is new too: the journal is a
general primitive and undo_batch does not filter on kind, so any other
importer's batches were reversible through this endpoint, carrying WINC's
references map - which lists none of that importer's tables, making every
reference check pass and every delete unconditional.

Nine tests. The two guards were verified by planting violations: dropping
dashboarddefaults from the references map, and passing creatable=None, each fail
the test written for them.

Scope: product

scripts/site_imports/journal.py

@@ -34,6 +34,8 @@ from datetime import datetime, timezone
 
 BATCH_APPLIED = 'applied'
 BATCH_UNDONE = 'undone'
+# See shopdb/core/models/importbatch.py for why this exists.
+BATCH_PARTIAL = 'partially-undone'
 
 OP_UPDATE = 'update'
 OP_INSERT = 'insert'
@@ -150,6 +152,9 @@ def undo_batch(connection, batchid, references=None):
         {'batchid': batchid}).fetchone()
     if batch is None:
         raise ValueError('unknown batchid: %s' % batchid)
+    # Only a FULLY undone batch is finished. A partially-undone one still has
+    # entries with isreverted = 0, and the whole point of retrying is to pick
+    # them up once whatever conflicted has been resolved.
     if batch[0] == BATCH_UNDONE:
         return UndoResult(batchid, 0, [])
 
@@ -184,10 +189,20 @@ def undo_batch(connection, batchid, references=None):
         else:
             conflicts.append(conflict)
 
+    # Record what actually happened, not what was attempted. Writing 'undone'
+    # unconditionally is what made a conflicted entry unrevertable: this call
+    # is the only way back, and the early return above refuses a second attempt
+    # on an undone batch.
+    #
+    # undoneat is stamped only when the batch is genuinely finished; on a
+    # partial it stays null, so "when was this reversed" keeps its meaning.
+    status = BATCH_PARTIAL if conflicts else BATCH_UNDONE
     connection.execute(text(
         'UPDATE importbatches SET status = :status, undoneat = :undoneat '
         'WHERE batchid = :batchid'),
-        {'status': BATCH_UNDONE, 'undoneat': _utcnow(), 'batchid': batchid})
+        {'status': status,
+         'undoneat': None if conflicts else _utcnow(),
+         'batchid': batchid})
 
     return UndoResult(batchid, reverted, conflicts)
 
@@ -218,10 +233,19 @@ def _revert_update(connection, table, targetid, column, oldvalue, newvalue):
 def _revert_insert(connection, batchid, table, targetid, references):
     """Hard-delete a row this batch created, only if nothing outside the batch
     still references it. Returns a Conflict when it is not safe, else None."""
-    from sqlalchemy import text
+    from sqlalchemy import inspect, text
 
     pk = _primary_key(connection, table)
+    # A reference table may not exist here. Some referrers are plugin-owned -
+    # notifications, for one - and a lean site drops the tables of plugins it
+    # does not install (ADR-014). Querying an absent table raises 1146 on MySQL,
+    # which rolls the whole undo back and leaves the batch permanently
+    # un-undoable on that site. Skip what is not there; a table that does not
+    # exist cannot hold a reference.
+    present = set(inspect(connection).get_table_names())
     for reftable, refcolumn in (references or {}).get(table, []):
+        if reftable not in present:
+            continue
         referencing = connection.execute(text(
             'SELECT COUNT(*) FROM %s WHERE %s = :targetid'
             % (reftable, refcolumn)), {'targetid': targetid}).fetchone()[0]