2026-07-12

🔧 Fixes & improvements

This release is housekeeping — four fixes that make existing behavior match what you'd expect, and one new guard rail.

✅ Statuses with an emptied work-type restriction accept work again

A status can be restricted to specific work types. If that list ended up empty — most commonly because the only work type it allowed was archived — DevStride wrongly read the empty list as "allows nothing" and rejected every item moved or created into that status with "Work type is not allowed in this lane."

An empty restriction now means what a missing one means: unrestricted. The fix applies consistently everywhere the rule is checked — creating items, moving them between statuses, and when a deleted status's residents are relocated.

The quiet beneficiary is Service Desk auto-close: on desks whose Closed status carried an emptied restriction, the automation was silently failing to move tickets. It now closes them as designed.

🛡️ Deleting a very full status now refuses cleanly instead of hanging

Deleting a status relocates every item still in it before the status is removed. For a status holding more than 1,000 items, that relocation can't complete within a single request — previously the delete could hang and time out partway.

DevStride now refuses the deletion up front with a clear message instead. Move or drain the status below the cap, then delete it. Statuses within the cap behave exactly as before.

🔍 Cycle filters that match nothing now return nothing

A filter scoped to cycles that resolve to no boards — for example, a relative cycle window on a team with no matching cycle — used to quietly widen to all items. It now returns the empty result it should, so saved views and exports scoped by cycle can't silently over-report.

📝 The Support Request form keeps its Description template

After submitting a Support Request, the form's Description now resets to your configured template instead of going blank for the next submission. Requester details still clear between submissions — that part is intentional.

🎯 SLA timers now record the policy that set their deadline

When a ticket's priority or customer importance changes and a different SLA policy takes over, the timer's deadline was always recalculated correctly — but the record of which policy set it wasn't updated. It is now, keeping SLA history accurate for the per-policy reporting on our roadmap.