Skip to content

include a teammember's trials when filtering by site#397

Merged
rkrenn merged 4 commits intomasterfrom
teammember_filter
Nov 25, 2025
Merged

include a teammember's trials when filtering by site#397
rkrenn merged 4 commits intomasterfrom
teammember_filter

Conversation

@rkrenn
Copy link
Copy Markdown
Collaborator

@rkrenn rkrenn commented Nov 25, 2025

Summary by CodeRabbit

  • Refactor

    • Improved internal query and join handling across multiple data layers to make permission- and department-based filtering more consistent and reliable.
    • Standardized identity-based filtering for team members and course lecturers so authorization checks apply uniformly across listings and schedules.
  • Chores

    • Updated internal UML/profile identifiers and metadata (no behavioral or public API changes).

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Nov 25, 2025

Walkthrough

Refactors DAO query construction to use explicit aliased joins and moves department/identity filters into new CriteriaUtil helper methods; adds two identity-filter override cases to the AuthorisationInterceptor; regenerates internal IDs in multiple UML profile files. (50 words)

Changes

Cohort / File(s) Summary
DAO criteria aliasing & identity filters
core/src/main/java/org/phoenixctms/ctsms/domain/CourseDaoImpl.java, core/src/main/java/org/phoenixctms/ctsms/domain/DutyRosterTurnDaoImpl.java, core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java, core/src/main/java/org/phoenixctms/ctsms/domain/MoneyTransferDaoImpl.java, core/src/main/java/org/phoenixctms/ctsms/domain/TimelineEventDaoImpl.java, core/src/main/java/org/phoenixctms/ctsms/domain/TrialDaoImpl.java, core/src/main/java/org/phoenixctms/ctsms/domain/VisitScheduleItemDaoImpl.java
Replace unnamed joins with explicit aliased Criteria (e.g., "course", "dutyRosterTurnTrial", "moneyTransferTrial", "timelineEventTrial", etc.) and replace direct department.id Restrictions with calls to CriteriaUtil.applyIdentityTeamMemberCriterion / CriteriaUtil.applyIdentityLecturerCriterion to apply identity-aware department constraints.
Criteria helper utilities
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java
Add applyIdentityTeamMemberCriterion and applyIdentityLecturerCriterion that build DetachedCriteria subqueries (TeamMemberImpl / LecturerImpl) tied to the aliased root and return exists()-based Criterion (fall back to provided OR criterion when identity is null).
Authorization overrides
core/src/main/java/org/phoenixctms/ctsms/intercept/AuthorisationInterceptor.java
Add two new parameter override cases: IDENTITY_TRIAL_TEAM_MEMBER_ID_FILTER and IDENTITY_COURSE_LECTURER_ID_FILTER; both validate current identity, enable write access, and prepare parameterValues mapping a target path root and the identity id.
UML profile metadata regeneration
mda/src/main/uml/UML_Standard_Profile.StandardProfileL3.profile.uml, mda/src/main/uml/andromda-common.andromda-service.profile.uml, mda/src/main/uml/andromda-presentation.profile.uml, mda/src/main/uml/andromda-process.profile.uml, mda/src/main/uml/andromda-webservice.profile.uml, mda/src/main/uml/andromda-xml.profile.uml
Bulk update of XMI/eAnnotations/md_id identifiers and related internal IDs; element names and public structure preserved; some extension memberEnd orders adjusted.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant DAO
  participant Criteria as "Hibernate Criteria (aliased)"
  participant CriteriaUtil
  participant DB

  Client->>DAO: call find...(params)
  DAO->>Criteria: createCriteria(root, "alias")
  alt department filter present
    Criteria->>CriteriaUtil: applyIdentity*(aliasCriteria, orConstraint?)
    CriteriaUtil->>Criteria: build DetachedCriteria exists(subQuery)
    Criteria->>Criteria: add(existsCriterion)
  else no identity
    Criteria->>Criteria: add(orConstraint if present)
  end
  Criteria->>DB: execute query
  DB-->>DAO: results
  DAO-->>Client: return results
Loading
sequenceDiagram
  participant Request
  participant AuthInterceptor
  participant IdentityStore
  participant Params

  Request->>AuthInterceptor: parameter override request (IDENTITY_*)
  AuthInterceptor->>IdentityStore: fetch current identity
  alt identity exists
    AuthInterceptor->>Params: set write access & set parameterValues [pathRoot, id]
    AuthInterceptor-->>Request: continue with override
  else no identity
    AuthInterceptor-->>Request: throw NOT_IDENTITY error
  end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • Areas to pay attention to:
    • Correct alias names and use of those aliases in subquery property paths (ensure alias matches the DetachedCriteria reference).
    • Semantics of left vs inner joins where joins were changed to aliased joins.
    • CriteriaUtil subquery correctness (property names, exists() usage) and null-identity fallback behavior.
    • AuthorisationInterceptor: parameterValues shape and integration with existing override handling.

Possibly related PRs

Suggested reviewers

  • SigridDeller
  • fladi

Poem

🐰
Joins renamed and queries hopped in line,
Subqueries peek where staff and trials align.
Aliases snug, identity checks in view,
A merry little rabbit says: "Good job — woohoo!"

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main change: adding support for including a team member's trials when filtering by site, which aligns with the core modifications across multiple DAO implementations that refactor department-based filtering to use identity-based criteria.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch teammember_filter

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)

20-33: Identity-based Criteria helpers look correct; optional small refactor only

The new applyIdentityTeamMemberCriterion / applyIdentityLecturerCriterion methods correctly:

  • Guard on a non-null Staff identity,
  • Tie TeamMemberImpl.trial.id / LecturerImpl.course.id to the passed criteria alias via eqProperty,
  • Fall back to the provided or criterion when identity is absent.

If you want to reduce duplication later, you could extract a small private helper that takes the target class and association property ("trial.id" / "course.id") as parameters, but it’s not necessary for correctness.

Also applies to: 132-164

core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (1)

147-151: Redundant second join on course; consider reusing the existing criteria

In handleFindByCourseParticipantDepartmentCategoryInterval, you first create:

Criteria courseCriteria = bookingCriteria.createCriteria("course", CriteriaSpecification.INNER_JOIN);

Then, for the department filter, you create another criteria on "course" with alias "inventoryCourse" just for applyIdentityLecturerCriterion:

CriteriaUtil.applyIdentityLecturerCriterion(
    bookingCriteria.createCriteria("course", "inventoryCourse", CriteriaSpecification.LEFT_JOIN),
    Restrictions.eq("department.id", courseDepartmentId.longValue()));

This results in two joins on the same association, which is likely unnecessary and can complicate the generated SQL and impact performance.

You can probably reuse courseCriteria (with or without an explicit alias) and avoid the extra LEFT_JOIN, for example:

-        Criteria courseCriteria = bookingCriteria.createCriteria("course", CriteriaSpecification.INNER_JOIN);
+        Criteria courseCriteria = bookingCriteria.createCriteria("course", CriteriaSpecification.INNER_JOIN);
         if (courseDepartmentId != null) {
-            CriteriaUtil.applyIdentityLecturerCriterion(
-                    bookingCriteria.createCriteria("course", "inventoryCourse", CriteriaSpecification.LEFT_JOIN),
-                    Restrictions.eq("department.id", courseDepartmentId.longValue()));
+            CriteriaUtil.applyIdentityLecturerCriterion(
+                    courseCriteria,
+                    Restrictions.eq("department.id", courseDepartmentId.longValue()));
         }

(Adjust aliasing if other usages in this PR depend on a specific alias name.)

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 21bd3b5 and 6244fa7.

📒 Files selected for processing (15)
  • core/src/main/java/org/phoenixctms/ctsms/domain/CourseDaoImpl.java (1 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/domain/DutyRosterTurnDaoImpl.java (3 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (3 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/domain/MoneyTransferDaoImpl.java (4 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/domain/TimelineEventDaoImpl.java (3 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/domain/TrialDaoImpl.java (2 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/domain/VisitScheduleItemDaoImpl.java (2 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/intercept/AuthorisationInterceptor.java (1 hunks)
  • core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (2 hunks)
  • mda/src/main/uml/UML_Standard_Profile.StandardProfileL3.profile.uml (1 hunks)
  • mda/src/main/uml/andromda-common.andromda-service.profile.uml (7 hunks)
  • mda/src/main/uml/andromda-presentation.profile.uml (7 hunks)
  • mda/src/main/uml/andromda-process.profile.uml (4 hunks)
  • mda/src/main/uml/andromda-webservice.profile.uml (5 hunks)
  • mda/src/main/uml/andromda-xml.profile.uml (4 hunks)
🧰 Additional context used
🧬 Code graph analysis (7)
core/src/main/java/org/phoenixctms/ctsms/domain/CourseDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
core/src/main/java/org/phoenixctms/ctsms/domain/TrialDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
core/src/main/java/org/phoenixctms/ctsms/domain/DutyRosterTurnDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
core/src/main/java/org/phoenixctms/ctsms/domain/VisitScheduleItemDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
core/src/main/java/org/phoenixctms/ctsms/intercept/AuthorisationInterceptor.java (1)
core/src/main/java/org/phoenixctms/ctsms/util/L10nUtil.java (1)
  • L10nUtil (48-1767)
core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
core/src/main/java/org/phoenixctms/ctsms/domain/MoneyTransferDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Build and Test
🔇 Additional comments (25)
mda/src/main/uml/UML_Standard_Profile.StandardProfileL3.profile.uml (1)

3-11: Auto-generated internal ID changes detected.

These changes consist solely of regenerated xmi:id attributes in eAnnotations and metadata elements. The element names, structure, and external references remain unchanged. Such ID regeneration typically occurs when UML modeling tools (e.g., MagicDraw) re-serialize model files.

If these changes are unintentional (i.e., side-effect of opening the model in an IDE), consider reverting to reduce diff noise. If intentional (e.g., model cleanup or tool upgrade), this is fine to proceed.

mda/src/main/uml/andromda-process.profile.uml (2)

4-93: Internal identifier regeneration throughout the profile.

All changes in this file are internal xmi:id attribute updates for eAnnotations, eClassifiers, and eStructuralFeatures. The stereotype names, attribute names, type references, and profile structure remain semantically identical.


199-278: Extension memberEnd order adjustments and metadata ID updates.

The memberEnd attribute order swaps in several Extension elements (e.g., lines 199, 205, 211, 217, 235) and the profileApplication/ModelLibrary ID updates are cosmetic changes that don't affect the functional behavior of the UML profile extensions.

mda/src/main/uml/andromda-xml.profile.uml (2)

4-86: Internal ID regeneration for XML profile classifiers.

The eAnnotations, eEnum, and eClass elements for XML-related stereotypes (XmlNsForm, TernaryBoolean, XmlAttribute, XmlSchemaType, XmlElement, XmlSchema, NoXml) have regenerated xmi:id values. All element names and type references are preserved.


108-265: Extension and metadata updates are cosmetic.

The memberEnd order adjustments and profileApplication/ModelLibrary ID changes follow the same pattern as other profile files and don't affect functionality.

mda/src/main/uml/andromda-webservice.profile.uml (2)

4-337: Extensive internal ID regeneration for webservice profile elements.

This file contains the most changes, but all are xmi:id attribute updates for the webservice-related enumerations (WebServiceStyle, WebServiceUse, WebServiceProvider, TernaryBoolean, HttpRequestType, ProviderMediaType, WSSecurityType, ParamType, WebServiceParameterStyle) and stereotypes (WebService, WebServiceOperation, WebFault, WebServiceParam, WebServiceFeed, WSSecurity, WSCustomHeader, WSAddressing, WSPolicy). All element names, literals, and structural features are preserved.


743-961: Extension memberEnd reordering and metadata ID updates.

The memberEnd order adjustments in Extension elements and profileApplication/ModelLibrary ID changes are consistent with the pattern observed across all profile files in this PR.

mda/src/main/uml/andromda-presentation.profile.uml (2)

4-202: Internal ID regeneration for presentation profile elements.

All eAnnotations, eEnum, and eClass elements for presentation-related stereotypes (WebActionFormScope, WebFieldType, WebActionType, WebExportType, ViewType, TernaryBoolean, FrontEnd* stereotypes) have regenerated xmi:id values while preserving all element names, attribute definitions, and type references.


541-648: Extension and metadata updates consistent with other profiles.

The memberEnd order adjustments and profileApplication/ModelLibrary ID updates follow the same pattern seen across all UML profile files in this PR.

mda/src/main/uml/andromda-common.andromda-service.profile.uml (1)

1-385: Based on the execution results and additional verification, I can now provide the final review comment.


UML profile regeneration is intentional and consistent with the PR objective.

The profile regeneration is confirmed to be part of the feature implementation. The commit message "add IDENTITY_TRIAL_TEAM_MEMBER_ID_FILTER" directly matches the PR objective about including team member trials when filtering by site. Both the service and common profiles were regenerated together as part of this feature addition.

The changes consist entirely of internal identifier regeneration (xmi:id attributes and cross-references). No public element names, enumeration values, or semantics were altered. This regeneration is standard behavior when UML modeling tools save profile modifications.

core/src/main/java/org/phoenixctms/ctsms/domain/TimelineEventDaoImpl.java (3)

82-101: Identity-aware department filter for trial join looks correct

Explicit alias "timelineEventTrial" and CriteriaUtil.applyIdentityTeamMemberCriterion are used consistently here, so department filtering now also includes trials where the current identity is a team member, while preserving the existing trialId / member filters. This matches the pattern used elsewhere in the PR.


116-135: Consistent identity-based department constraint in status/type query

The same aliased join plus applyIdentityTeamMemberCriterion pattern is applied for the status/type query, keeping semantics aligned with the interval method while adding identity-based access.


143-171: SubCriteriaMap usage with identity filter is coherent

Using criteriaMap.createCriteria("trial", "timelineEventTrial") as the target for applyIdentityTeamMemberCriterion is consistent with the helper’s alias expectations and with surrounding criteria-map usage; no issues seen.

core/src/main/java/org/phoenixctms/ctsms/domain/CourseDaoImpl.java (1)

261-274: Identity-based lecturer extension of department filter is implemented cleanly

Creating the criteria with alias "course" and routing the department restriction through CriteriaUtil.applyIdentityLecturerCriterion is consistent with the new identity pattern and should correctly broaden results to include courses where the current identity is a lecturer even outside the selected department.

core/src/main/java/org/phoenixctms/ctsms/domain/VisitScheduleItemDaoImpl.java (2)

460-482: Trial join alias and identity team‑member criterion are wired correctly

Using alias "visitScheduleItemTrial" for the trial join and passing CriteriaUtil.applyOr(..., idCriterion) into applyIdentityTeamMemberCriterion keeps the previous (department OR id) behaviour while extending it to include trials where the current identity is a team member. The reuse of idCriterion in both the trialId and department clauses also preserves the “always include this id if specified” semantics.


488-511: Status/type interval now respects identity for department-filtered trials

The aliased "visitScheduleItemTrial" join plus applyIdentityTeamMemberCriterion(trialCriteria, Restrictions.eq("department.id", ...)) matches the helper’s expectations and the pattern used elsewhere in the PR; the added identity-based OR is the only behavioural change here.

core/src/main/java/org/phoenixctms/ctsms/intercept/AuthorisationInterceptor.java (1)

371-441: New identity-based filter overrides follow the established pattern

The IDENTITY_TRIAL_TEAM_MEMBER_ID_FILTER and IDENTITY_COURSE_LECTURER_ID_FILTER branches mirror the existing *_DEPARTMENT_ID_FILTER implementations: they enforce presence of an identity, seed a PSFVO when needed, and inject the appropriate property path plus the identity id as a string. This looks consistent with how other parameter overrides are applied.

Please double-check that:

  • The ServiceMethodParameterOverride enum declares these exact constants.
  • Any permissions or service-method metadata that should use these overrides have been updated accordingly.
core/src/main/java/org/phoenixctms/ctsms/domain/TrialDaoImpl.java (2)

73-89: Department payoffs query correctly extended with identity-team-member semantics

Switching to createTrialCriteria("trial") and wrapping the department restriction in CriteriaUtil.applyIdentityTeamMemberCriterion is consistent with the helper’s design and with other DAOs, broadening results to “department OR identity is team member” without touching payoff logic.


102-118: ECRF-based trial lookup uses alias + identity helper coherently

Using alias "trial0" for both the main criteria and the ECRF subquery, and applying applyIdentityTeamMemberCriterion on the department filter, keeps the subquery correlation intact while adding the intended identity-based trial inclusion.

core/src/main/java/org/phoenixctms/ctsms/domain/DutyRosterTurnDaoImpl.java (3)

204-244: Duty-roster interval query: identity-aware trialDepartment filter is sound

The aliased "dutyRosterTurnTrial" join plus applyIdentityTeamMemberCriterion wrapping Restrictions.or(isNull("dutyRosterTurn.trial"), department match) preserves the old “include unassigned or matching department” behaviour and extends it to also include trials where the current identity is a team member. This looks correct.


291-319: Calendar autocomplete correctly reuses the identity-team-member pattern

For calendar lookup, the same aliased join and OR-wrapped department condition are fed through applyIdentityTeamMemberCriterion, giving consistent identity-based broadening of trialDepartment-filtered results.


321-350: Title autocomplete adopts the same identity-aware department filter

The title autocomplete query mirrors the calendar query’s use of "dutyRosterTurnTrial" and applyIdentityTeamMemberCriterion, so behaviour stays consistent across both endpoints.

core/src/main/java/org/phoenixctms/ctsms/domain/MoneyTransferDaoImpl.java (2)

97-129: Cost-type helper now cleanly incorporates identity-team-member trials

Changing the trial join to "moneyTransferTrial" and wrapping Restrictions.or(isNull("moneyTransfer.trial"), department match) with CriteriaUtil.applyIdentityTeamMemberCriterion preserves the previous department/null-trial logic while additionally permitting trials where the current identity is in the team. Helper behaviour remains backwards-compatible aside from the intended identity broadening.


157-197: Finder by proband/trial/method/costType uses aliased trial join with identity helper correctly

In handleFindByProbandTrialMethodCostTypePaidPerson, the aliased "moneyTransferTrial" join via criteriaMap.createCriteria and subsequent call to applyIdentityTeamMemberCriterion mirror the helper usage above and should behave identically, while leaving proband/“person” filtering and PSF application unchanged.

core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (1)

183-185: Identity-based trial department filter is consistent with helper semantics

Using CriteriaUtil.applyIdentityTeamMemberCriterion here cleanly encapsulates the new behavior:

  • If trialDepartmentId is provided and the user has an identity, results match either the chosen department or trials where the user is a team member.
  • If there is no identity, behavior degrades to the original simple department.id = trialDepartmentId filter.

The alias "inventoryTrial" is also compatible with the helper’s eqProperty("trial.id", alias + ".id") logic.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (1)

147-151: Avoid duplicating course joins when applying lecturer identity filter

In this method you now have:

  • an inner join courseCriteria = bookingCriteria.createCriteria("course", CriteriaSpecification.INNER_JOIN);
  • plus a second left join bookingCriteria.createCriteria("course", "inventoryCourse", CriteriaSpecification.LEFT_JOIN) used only for the identity/dept restriction.

This creates two joins to the same association where one would suffice and slightly complicates the generated SQL.

Consider reusing the existing courseCriteria (possibly giving it an alias) when applying the identity criterion, e.g.:

-        Criteria courseCriteria = bookingCriteria.createCriteria("course", CriteriaSpecification.INNER_JOIN);
-        if (courseDepartmentId != null) {
-            CriteriaUtil.applyIdentityLecturerCriterion(bookingCriteria.createCriteria("course", "inventoryCourse", CriteriaSpecification.LEFT_JOIN),
-                    Restrictions.eq("department.id", courseDepartmentId.longValue()));
-        }
+        Criteria courseCriteria = bookingCriteria.createCriteria("course", CriteriaSpecification.INNER_JOIN);
+        if (courseDepartmentId != null) {
+            CriteriaUtil.applyIdentityLecturerCriterion(
+                    courseCriteria,
+                    Restrictions.eq("department.id", courseDepartmentId.longValue()));
+        }

This keeps behavior while avoiding a redundant join.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6244fa7 and e684ed1.

📒 Files selected for processing (1)
  • core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (1)
core/src/main/java/org/phoenixctms/ctsms/query/CriteriaUtil.java (1)
  • CriteriaUtil (57-1148)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Build and Test
🔇 Additional comments (2)
core/src/main/java/org/phoenixctms/ctsms/domain/InventoryBookingDaoImpl.java (2)

90-97: Identity-based department filters for course/trial look correct

Using CriteriaUtil.applyIdentityLecturerCriterion and CriteriaUtil.applyIdentityTeamMemberCriterion with an OR on (department IS NULL OR department = ?) matches the intent to include both site-based appointments and those linked to the current lecturer/teammember. The null-identity fallback keeps the legacy department-only behavior. This is consistent and safe.


183-184: Team-member–aware trial department filtering is consistent with helper semantics

Switching the trial-department branch to CriteriaUtil.applyIdentityTeamMemberCriterion with a department.id restriction cleanly extends the query to include both:

  • trials at the given department, and
  • trials where the current identity is a team member (when identity is present),

while preserving the original behavior when identity is absent. This aligns with the stated PR objective.

@rkrenn rkrenn merged commit 6b99420 into master Nov 25, 2025
2 checks passed
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.

1 participant