Map the saved request from the evidence-file lookup, and teach the shared-dispatch
conflict test to return that lookup so a winning insert still produces a response.
Co-authored-by: Arthur Bassi <bassi-arthurr@users.noreply.github.com>
Upload and status use the same dispatch create already selects, so a work
order with no primary can still attach evidence. Status no longer rejects a
terminal work order or dispatch, and create, cancel, and revoke return the
stored evidence file name and attachments.
Co-authored-by: Arthur Bassi <bassi-arthurr@users.noreply.github.com>
UpdateWorkOrderAsync loaded the work order, applied the shared schedule
side effects (RescheduleCount, OriginalDate/OriginalWeek, lifecycle,
IsAddOn) and saved with no gate, transaction or row lock, so a
concurrent reschedule could interleave with the read-modify-write.
The read, the mutation, the save and the audit entry now run through
IWorkOrderDataService.ExecuteWorkOrderMutationAsync, which uses the
shared WorkOrderMutationLock: the per-work-order in-process gate, a
transaction, and an UPDLOCK on the work order row on SQL Server. A
reschedule committed by another holder of the lock is read before the
edit applies its own date and increments RescheduleCount.
Adds a regression test that holds the gate, commits a reschedule, and
asserts the edit waits and then builds on the committed schedule.
Route edit-path ScheduledDate changes through WorkOrderBoardFieldMutations.ApplyScheduledDate so OriginalDate/OriginalWeek, RescheduleCount and lifecycle promotion match the board PATCH path, and audit those changes.
Auto-approved evidence was hidden because download checked the approval tier. Viewers of the work order can open it, and a request can store more than one scanned document.
The route contract keeps the poc endpoint from main and the uplift evidence routes from this branch. Create still passes the scanned evidence document through the locked mutation.
The legacy ingest batch holds the per-work-order lock, taken in id order,
for every work order it may cancel until the batch commits. A vendor
uplift request now runs under the same lock. Uplift creation on both
routes refuses a work order cancelled by either lifecycle or status text,
so a request can neither slip past a cancel nor land after one.
A token carries the user's roles and account, so a demoted admin kept admin
claims until the token expired. The team member update and the admin user
edit now rotate the security stamp and evict the cached value when the role,
account or user name changes. Permission overrides are read per request and
are not in the token.
Tokens now carry a keyed hash of the account's security stamp, and every
authenticated request compares it with the stored stamp (cached for 60 s,
evicted in-process on change). A password reset or change, a deactivation
and a deletion all rotate or remove the stamp, so tokens issued before them
get 401. Tokens without the claim get 401 too.
The ingest writes only the status text, so the shared helper gains a
status-text form of the same rule and the ingest stages the same
sync-attributed cancellation in its batch save.
The webhook and reconciliation saves now stage the same pending-uplift
cancellation, with its own sync audit row, as the board cancel. The rule
and the write live in one data-layer helper so the paths cannot drift.
The board and slide-over cancel a work order through the lifecycle status
patch, which set Canceled without touching uplifts, so a pending uplift
stayed in the approval queue. A patch to Canceled now withdraws pending
uplifts in the same save, each with its own uplift_cancel audit entry, and
runs under the per-work-order gate uplift create uses.
An admin revoke overturns a human decision, so admins may revoke only
admin-approved uplifts. The work-order revoke path let an admin revoke an
auto-approved uplift they had requested themselves. Both revoke endpoints
now refuse it; dispatchers keep revoking their own auto-approved uplifts.
SendCodeAsync validates the invite, then starts the code with a conditional
update that also requires the invite to still be open. When an admin revoked
the link (or it was used) between those two reads, the refusal was reported as
resend_too_soon with a Retry-After, although the link was already dead.
On a refused start the invite is now read again: a closed invite gets the same
generic invalid_invite response as any other dead link, and a cooldown or send
limit refusal is computed from the fresh row.
A standalone severity patch on an Overdue WO still stores the value,
because the board patches severity before type when correcting Overdue
to Emergency/Reactive and that write must not be dropped or rejected.
Project the severity as null for Overdue in the board row mapping, which
also feeds the PATCH response, search results and the detail view, so a
stored value never surfaces on a type that carries no severity.
- Forgot Password is limited to 3 codes an hour and 10 a day per email, and
an account gets 10 failed code checks a day across every code it is sent,
so new client addresses and new codes no longer buy more guesses. Refused
requests answer exactly like accepted ones.
- The reset email is queued to a background sender, and unregistered
addresses store a row no code can match, so both paths do the same work
and return without waiting on the mail provider. Each request also clears
expired codes.
- Code hashes are HMAC-SHA256 under a key derived with HKDF from the JWT
signing secret; rows in the previous unkeyed format stop matching.
- Email and code are read only from the JSON body.
Two concurrent first requests can leave two pending codes for one email.
Exhausting or using one now deletes all of them, so a sibling code cannot
become live afterwards.