Skip to content

[bot] Merge 25.7 to 25.11#1160

Open
github-actions[bot] wants to merge 3 commits into
release25.11-SNAPSHOTfrom
25.11_fb_bot_merge_25.7
Open

[bot] Merge 25.7 to 25.11#1160
github-actions[bot] wants to merge 3 commits into
release25.11-SNAPSHOTfrom
25.11_fb_bot_merge_25.7

Conversation

@github-actions

Copy link
Copy Markdown

Generated automatically.
Merging changes from: 34d2839
Approve all matching PRs simultaneously.
Approval will trigger automatic merge.
Verify all PRs before approving: https://internal.labkey.com/Scrumtime/Backlog/harvest-gitOpenPullRequests.view?branch=25.11_fb_bot_merge_25.7

labkey-martyp and others added 3 commits June 22, 2026 13:40
#### Rationale

EHR_BillingManager.deleteBillingRuns() filtered the invoice,
invoicedItems, and miscCharges tables by objectid/invoiceId alone, with
no container clause. Since DeleteBillingPeriodAction only checks
EHR_BillingAdminPermission in the current container, a billing admin in
one container could delete invoices and invoiced items, or detach misc
charges, in any other container by submitting foreign objectids. All
filters are now container-scoped via
SimpleFilter.createContainerFilter().

#### Related Pull Requests

* None

#### Changes

* EHR_BillingManager: all delete/preview filters in deleteBillingRuns()
are now container-scoped via a new createContainerScopedInFilter()
helper.
* EHR_BillingManager.TestCase: new integration test that seeds a
complete billing run in each of two folders and verifies cross-container
ids are ignored by both the testOnly preview and the actual delete,
while same-container deletion still removes the run and detaches its
misc charges.
* EHR_BillingModule: registers the test via getIntegrationTests().
…ner authz (#1152)

#### Rationale
Two related EHR security items surfaced during a security review. (1)
EHRDemographicsService serves animal records built under the elevated
EHR service user (EHRService.getEHRUser), so callers receive aggregated
demographic/derived fields regardless of their per-dataset / QCState row
permissions — and many DemographicsProviders set _supportsQCState=false,
applying no QCState filter at all. This is intended behavior (within an
EHR study folder, Read access is the trust boundary for the demographics
summary, which backs the shared EHR.DemographicsCache UIs), so it is now
documented in code to prevent a future caller from re-exposing these
records at a lower trust boundary. (2)
SetGeneticCalculationTaskSettingsAction enforced AdminPermission only on
the request container while resolving and acting on a caller-supplied
containerPath for the server-global genetic-calculation schedule, so a
user who administers the request container could point the schedule at a
container they do not administer. That gap is closed and covered by an
integration test.

#### Related Pull Requests
* None

#### Changes
* Document elevated-access-by-design on
EHRDemographicsServiceImpl.getAnimals and
EHRController.GetDemographicsAction, warning callers not to forward
these records to a lower trust boundary without re-securing them against
the consuming user.
* Re-verify AdminPermission on the resolved target container in
SetGeneticCalculationTaskSettingsAction and throw UnauthorizedException
when the caller does not administer it.
* Add EHRController.TestCase, an integration test verifying that a user
who administers the request container but not the resolved target is
rejected while a user who administers the target succeeds; registered in
EHRModule.getIntegrationTests().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants