[bot] Fast-forward for 26.9.0 - #764
Merged
Merged
Conversation
…747) ## Rationale The cagemates demographics query could report animals as current cagemates when they were not. The joined housing row was filtered only on the animal being alive, so housing records that had already ended, and records still in a non-public QC state, counted toward both the cagemate list and the total. Separately, a housing row whose location does not resolve through the cage lookup carries no location at all — 101 such rows exist in the container we checked — and those need to be excluded deliberately rather than left to drop out of the results as a side effect of null comparison. ## Changes - Apply the same current-housing and public-QC-state filters to both sides of the cagemates self-join, so only housing that is genuinely open and visible contributes. - Exclude housing rows with no resolved location, so they cannot collapse into one shared facility-wide group. - Drop a redundant room comparison, since room is derived from the location key and adds nothing once the locations match.
## Rationale The Observations form let a user pick any observation type but stored every entry as Clinical, so behavior observations recorded there were filed as clinical and dropped out of the behavior views. The form cannot know the right value up front because it depends on which type the user picks for each row, so the type is now derived on save from that type's category. The behavior forms had the same mismatch from the other direction: their Daily Observations shortcut bypassed the type-filtered picker and wrote clinical-category observations and orders labeled as behavior. Rows already saved with a mismatched type need a one-time data fix; this change only affects new entries. ## Changes - The Observations form no longer defaults an observation's type. The trigger script derives it from the selected observation type's category, while every other form continues to set the type explicitly, including scheduled entries that inherit it from their order. - The Daily Observations shortcut is now opt-in per form section rather than always present, so it appears only on the clinical forms.
…ed birth/arrival times (#751) ## Rationale Three NIRC updates: the death notification now fires for a death recorded alongside its necropsy, the Submit For Review dialog no longer shows a duplicate Assign To field when reopened, and birth and arrival entry now keeps the time of day. The notification and the accompanying procedure-order update were keyed off the 'Request: Pending' state. A death entered on the same form as its necropsy is submitted straight to 'Review Required' or 'Completed' and never passes through that state, so neither ran for it. The Submit For Review dialog claimed a page-wide element name for its Assign To field and only hid itself when cancelled, so a second open rendered the previous dialog's field next to the new one. Cancelling to correct a value and reopening is routine in the combined death-and-necropsy flow, which is where it showed up. Times were lost twice over: neither date column carried a format with a time component, so both forms presented a date-only editor, and the birth trigger separately discarded the time server-side, which carried through to the records derived from the birth date. ## Changes - The deaths trigger keys the notification off the move out of draft instead of off one specific target state, so it fires once per record no matter which submit button created it. - The procedure-order update moves with the notification, so it also runs for a death recorded alongside its necropsy. - The Submit For Review dialog no longer claims a page-wide element name and now discards itself when cancelled, so reopening it renders a single Assign To field. - The birth and arrival date columns declare a date-and-time display format, so entry offers a time-of-day editor and the stored time is visible. - The birth trigger no longer discards the time from the birth date, so it survives onto the birth record and everything derived from it.
## Rationale The Rearrival form collects fields that do not apply to a returning animal and omits the ones that do, and a completed rearrival leaves the animal in a departed state. It asks for an acquisition type and a CITES number, though an animal that is coming back was already acquired, and it does not ask which project, which protocol or which location the animal returns to. A departure closes the animal's project assignment, protocol assignment and housing records, so a rearrival has to open them again, and it has to put the animal back to Alive. ## Related Pull Requests - LabKey/ehrModules#1200 — needed alongside this change, since entering a death for an animal that has arrived more than once fails without it. ## Changes - Replace acquisition type and CITES on the Rearrival form with project, protocol and location, each required, as they are on the Arrival form. - Open the project assignment, protocol assignment and housing records for a rearrival, matching what an arrival already does. - Return a rearrived animal to Alive once the rearrival is completed. - Add a Selenium test covering the fields the form collects, the records a rearrival opens and the status change.
DariaBod
approved these changes
Sep 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Generated automatically.
Approve all matching PRs simultaneously.
Approval will trigger automatic merge.
View all PRs: https://internal.labkey.com/Scrumtime/Backlog/harvest-gitOpenPullRequests.view?branch=26.9_ff_bot_26.9.0