Skip to content

Consultation table filters#2480

Open
sebastian-j-ibanez wants to merge 4 commits into
developfrom
feat/consultation-filters-develop
Open

Consultation table filters#2480
sebastian-j-ibanez wants to merge 4 commits into
developfrom
feat/consultation-filters-develop

Conversation

@sebastian-j-ibanez

@sebastian-j-ibanez sebastian-j-ibanez commented Jun 19, 2026

Copy link
Copy Markdown
Collaborator

Changes Made

  • Add Consultant and Provider filter inputs on the consultations page.
  • Extend ConsultationRequestDao with an overloaded getConsultationDTOs(), for the consultant and provider filters.
  • Add getDistinctConsultants() and getDistinctConsultProviders() queries to populate filter options.
  • Pass Consultant and Provider filters to the DAO via EctViewConsultationRequestsUtil and EctViewConsultationRequests2Action.
  • Reset pagination and clear stale filter ids on submit.
  • Parameterize legacy getConsults() to fix a SQL injection.

Summary by Sourcery

Add consultant and provider filtering to the consultations view and improve safety of consultation queries.

New Features:

  • Introduce consultant and provider filters with autocomplete inputs on the consultations page that combine with existing team/date/completed filters and sorting.

Bug Fixes:

  • Parameterize legacy consultation query filters to prevent SQL injection vulnerabilities.

Enhancements:

  • Extend consultation DAO and utilities to support optional consultant and provider filters and expose distinct consultants/providers for populating filter options.
  • Reset pagination and clear inconsistent filter selections when submitting the consultation search form.
  • Apply site/team privacy constraints to provider filter options in the consultations view.

Summary by cubic

Adds Consultant and Provider autocomplete filters to the Consultations page, integrating with existing filters and sorting, and strengthens query safety and input validation.

  • New Features

    • Consultant and Provider autocomplete filters; work with existing team/date/completed filters and sorting; pagination resets and hidden IDs are sanitized across submit, sort, and paging.
    • Distinct options loaded via DAO; provider list respects site/team privacy and ignores out-of-scope selections; added DAO overload for optional consultantId and filterProviderNo, wired through the action and util.
  • Bug Fixes

    • Parameterized legacy getConsults() to prevent SQL injection.
    • Hardened filter validation in ViewConsultationRequests to drop mismatched text/ID pairs and crafted provider values.

Written for commit d507313. Summary will update on new commits.

Review in cubic

Summary by CodeRabbit

  • New Features
    • Added new filtering options for consultation requests by consultant and patient provider/MRP
    • Implemented autocomplete functionality to simplify consultant and provider selection
    • Filters integrate seamlessly with existing consultation request search and sorting features for more refined results

@sebastian-j-ibanez sebastian-j-ibanez self-assigned this Jun 19, 2026
@sebastian-j-ibanez sebastian-j-ibanez linked an issue Jun 19, 2026 that may be closed by this pull request
2 tasks
@github-actions

github-actions Bot commented Jun 19, 2026

Copy link
Copy Markdown

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA d507313.
Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Files

None

@sourcery-ai

sourcery-ai Bot commented Jun 19, 2026

Copy link
Copy Markdown

Reviewer's Guide

Adds consultant and provider autocomplete filters to the consultations page, wires their values through the action/util/DAO layers into the DTO query, and parameterizes a legacy consultation retrieval query to avoid SQL injection.

Sequence diagram for consultations search with consultant/provider filters

sequenceDiagram
    actor User
    participant ViewConsultationRequests_jsp as ViewConsultationRequests.jsp
    participant EctViewConsultationRequests2Action
    participant EctViewConsultationRequestsUtil
    participant ConsultationRequestDaoImpl

    User->>ViewConsultationRequests_jsp: submit consultSearchForm
    ViewConsultationRequests_jsp->>EctViewConsultationRequests2Action: ViewConsultation.do
    EctViewConsultationRequests2Action->>ViewConsultationRequests_jsp: setAttribute consultantId, filterProviderNo
    ViewConsultationRequests_jsp->>EctViewConsultationRequestsUtil: estConsultationVecByTeam(..., consultantId, filterProviderNo)
    EctViewConsultationRequestsUtil->>ConsultationRequestDaoImpl: getConsultationDTOs(..., consultantId, filterProviderNo)
    ConsultationRequestDaoImpl->>ConsultationRequestDaoImpl: buildConsultationDTOQuery(..., consultantId, filterProviderNo)
    ConsultationRequestDaoImpl-->>EctViewConsultationRequestsUtil: List<ConsultationListDTO>
    EctViewConsultationRequestsUtil-->>ViewConsultationRequests_jsp: populate consultation list
    ViewConsultationRequests_jsp-->>User: render filtered consultations
Loading

Sequence diagram for loading consultant/provider autocomplete options

sequenceDiagram
    actor User
    participant ViewConsultationRequests_jsp as ViewConsultationRequests.jsp
    participant ConsultationRequestDaoImpl

    User->>ViewConsultationRequests_jsp: request consultations page
    ViewConsultationRequests_jsp->>ConsultationRequestDaoImpl: getDistinctConsultants()
    ConsultationRequestDaoImpl-->>ViewConsultationRequests_jsp: List<ProfessionalSpecialist>
    ViewConsultationRequests_jsp->>ConsultationRequestDaoImpl: getDistinctConsultProviders()
    ConsultationRequestDaoImpl-->>ViewConsultationRequests_jsp: List<Provider>
    ViewConsultationRequests_jsp-->>User: render autocomplete filters (consultant, provider)
Loading

File-Level Changes

Change Details Files
Add consultant and provider autocomplete filters to the consultations list view with stateful selections and pagination reset.
  • Import ProfessionalSpecialist and Provider models into the consultations JSP and read consultant/provider filter attributes from the request.
  • Query distinct consultants and consultation-related providers in the JSP, applying site/team provider filtering and computing labels for currently selected values.
  • Render consultant and provider text inputs plus hidden id fields, wired to the existing consultation search form, and reset offset to 0 on submit.
  • Initialize jQuery UI autocomplete widgets for both filters with client-side option arrays, keeping hidden ids in sync and clearing stale ids when the entered text does not match a known option.
src/main/webapp/oscarEncounter/oscarConsultationRequest/ViewConsultationRequests.jsp
Thread consultant and provider filters through the action and utility layers into the DAO-backed consultation query.
  • Add consultantId and filterProviderNo properties (with getters/setters) to EctViewConsultationRequests2Action and expose them as request attributes.
  • Overload EctViewConsultationRequestsUtil.estConsultationVecByTeam to accept consultantId and filterProviderNo, delegating the original signature to the new one.
  • Update the JSP to call the new estConsultationVecByTeam overload, passing consultantId and filterProviderNo so they participate in existing retrieval and pagination logic.
src/main/java/ca/openosp/openo/encounter/oscarConsultationRequest/pageUtil/EctViewConsultationRequests2Action.java
src/main/java/ca/openosp/openo/encounter/oscarConsultationRequest/pageUtil/EctViewConsultationRequestsUtil.java
src/main/webapp/oscarEncounter/oscarConsultationRequest/ViewConsultationRequests.jsp
Extend the consultation DAO to support consultant/provider filtering and to expose distinct consultant and provider lists for filters.
  • Add an overloaded ConsultationRequestDao.getConsultationDTOs variant that accepts consultantId and filterProviderNo parameters while preserving the original method for backward compatibility.
  • Extend buildConsultationDTOQuery to accept consultantId and filterProviderNo, appending JPQL predicates and positional parameters when provided.
  • Implement getDistinctConsultants() using a DISTINCT join from ConsultationRequest to ProfessionalSpecialist ordered by last/first name.
  • Implement getDistinctConsultProviders() using a DISTINCT join from ConsultationRequest to Demographic and Provider to obtain consulting patient MRPs ordered by last/first name.
  • Declare the new overloaded getConsultationDTOs and list retrieval methods in ConsultationRequestDao with Javadoc describing semantics and defaults.
src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDaoImpl.java
src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDao.java
Parameterize the legacy consultation list query to avoid SQL injection in team and date filters.
  • Replace string-concatenated team, startDate, and endDate conditions in ConsultationRequestDaoImpl.getConsults with named parameters.
  • Set the newly introduced named parameters on the JPA Query instance only when the corresponding values are present, preserving existing behavior for null/empty inputs.
  • Keep pagination behavior (offset and max results) unchanged while improving query safety.
src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDaoImpl.java

Assessment against linked issues

Issue Objective Addressed Explanation
https://github.com/openo-beta/Open-O/issues/2455 Add a consultant filter on the consultations page that allows users to select from available consultants and restrict the table to consultations for the chosen consultant.
https://github.com/openo-beta/Open-O/issues/2455 Add a provider filter on the consultations page that allows users to select from available providers and restrict the table to consultations for the chosen provider.
https://github.com/openo-beta/Open-O/issues/2455 Ensure both consultant and provider filters are optional (do not filter by default) and work in combination with each other and existing filters (date range, completed/uncompleted, team), including correct wiring through DAO, utilities, and action layer.

Possibly linked issues

  • #2455: PR implements the requested consultant and provider filters on the Consultations page, matching the issue’s requirements exactly.

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@coderabbitai

coderabbitai Bot commented Jun 19, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The PR extends consultation request filtering by adding consultant (consultantId) and provider (filterProviderNo) as optional filter parameters across the full stack: the ConsultationRequestDao interface gains new overloaded and distinct-list methods, the DAO implementation adds conditional JPQL predicates, the service utility and Struts action wire the new parameters, and the JSP adds autocomplete inputs backed by jQuery UI with server-side distinct value lists.

Changes

Consultant & Provider Filtering for Consultation Requests

Layer / File(s) Summary
DAO interface: new filter and distinct-list methods
src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDao.java
Adds imports for ProfessionalSpecialist and Provider, a new getConsultationDTOs overload with consultantId/filterProviderNo parameters, getDistinctConsultants(), and getDistinctConsultProviders().
DAO implementation: parameterized queries and filter predicates
src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDaoImpl.java
Refactors getConsults to named JPQL parameters; adds the getConsultationDTOs overload delegating to an extended buildConsultationDTOQuery which appends conditional predicates for specialist.id and mrp.ProviderNo; replaces distinct-list methods with typed JPQL distinct joins.
Service utility and Struts action wiring
src/.../pageUtil/EctViewConsultationRequestsUtil.java, src/.../pageUtil/EctViewConsultationRequests2Action.java
estConsultationVecByTeam gains a new overload forwarding consultantId/filterProviderNo to the DAO; the old overload delegates with null. The Struts action adds fields, request attribute propagation, and getters/setters for both parameters.
JSP filter UI: autocomplete and query wiring
src/main/webapp/oscarEncounter/oscarConsultationRequest/ViewConsultationRequests.jsp
Reads and normalizes filter params server-side, fetches distinct consultant/provider lists with privacy restrictions, loads jQuery UI, renders text inputs and hidden ID fields, attaches autocomplete with submit-time validation and pagination reset, and passes filter args to the results query.

Sequence Diagram

sequenceDiagram
    participant User
    participant AutocompleteJS as jQuery UI Autocomplete
    participant consultSearchForm as Search Form
    participant EctAction as EctViewConsultationRequests2Action
    participant Util as EctViewConsultationRequestsUtil
    participant DaoImpl as ConsultationRequestDaoImpl

    User->>AutocompleteJS: types consultant/provider name
    AutocompleteJS->>consultSearchForm: sync hidden consultantId / filterProviderNo
    User->>consultSearchForm: submit (offset reset to 0)
    consultSearchForm->>EctAction: POST consultantId, filterProviderNo
    EctAction->>Util: estConsultationVecByTeam(..., consultantId, filterProviderNo)
    Util->>DaoImpl: getConsultationDTOs(..., consultantId, filterProviderNo)
    DaoImpl->>DaoImpl: buildConsultationDTOQuery with specialist.id / mrp.ProviderNo predicates
    DaoImpl-->>Util: List~ConsultationListDTO~
    Util-->>EctAction: populated consultation list
    EctAction-->>User: filtered results rendered in JSP
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • D3V41

Poem

🐰 Hop, hop, through the code we go,
New filters added, top to bottom — oh!
Distinct consultants, providers too,
Autocomplete magic shining through.
From JPQL joins to jQuery's grace,
The rabbit stamps ✅ on every place!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Consultation table filters' directly reflects the main objective of the PR—adding filtering functionality to the consultation table via consultant and provider filters.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/consultation-filters-develop

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.

@sebastian-j-ibanez sebastian-j-ibanez marked this pull request as ready for review June 19, 2026 20:39
@qodo-code-review

Copy link
Copy Markdown

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Code Review

This pull request introduces optional consultant and patient provider (MRP) filters to the consultation requests view. It updates the DAO layer, action classes, and the JSP page to fetch distinct lists of consultants and providers and display them as searchable autocomplete dropdowns. The review comments correctly identify critical bugs in ConsultationRequestDaoImpl.java where capitalized property names are used in JPQL queries instead of camelCase, which would result in runtime QuerySyntaxExceptions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Hey - I've found 1 issue, and left some high level feedback:

  • The JSP now instantiates ConsultationRequestDao and runs distinct consultant/provider queries directly; consider moving these lookups (and the site/team filtering) into the action/util layer and passing the result via request attributes to keep data access out of the view and avoid duplicating privacy logic.
  • In getDistinctConsultProviders(), the JPQL uses JOIN Demographic d ON d.DemographicNo = cr.demographicId JOIN Provider mrp ON mrp.ProviderNo = d.ProviderNo; it would be more robust and readable to join via mapped entity relationships and entity field names instead of column names and explicit ON conditions.
  • The JSP adds its own jquery-3.6.4 and jquery-ui-1.12.1 includes; please verify there isn't an existing global jQuery instance and, if there is, reuse it or use noConflict to avoid version conflicts and duplicated script payload.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The JSP now instantiates `ConsultationRequestDao` and runs distinct consultant/provider queries directly; consider moving these lookups (and the site/team filtering) into the action/util layer and passing the result via request attributes to keep data access out of the view and avoid duplicating privacy logic.
- In `getDistinctConsultProviders()`, the JPQL uses `JOIN Demographic d ON d.DemographicNo = cr.demographicId JOIN Provider mrp ON mrp.ProviderNo = d.ProviderNo`; it would be more robust and readable to join via mapped entity relationships and entity field names instead of column names and explicit `ON` conditions.
- The JSP adds its own `jquery-3.6.4` and `jquery-ui-1.12.1` includes; please verify there isn't an existing global jQuery instance and, if there is, reuse it or use `noConflict` to avoid version conflicts and duplicated script payload.

## Individual Comments

### Comment 1
<location path="src/main/webapp/oscarEncounter/oscarConsultationRequest/ViewConsultationRequests.jsp" line_range="195-203" />
<code_context>
+        // privacy filter used elsewhere on this page to the provider list.
+        ConsultationRequestDao consultReqDaoForFilters = SpringUtils.getBean(ConsultationRequestDao.class);
+        List<ProfessionalSpecialist> distinctConsultants = consultReqDaoForFilters.getDistinctConsultants();
+        List<Provider> distinctConsultProviders = consultReqDaoForFilters.getDistinctConsultProviders();
+        if (isSiteAccessPrivacy || isTeamAccessPrivacy) {
+            List<Provider> filteredProviders = new ArrayList<Provider>();
+            for (Provider pv : distinctConsultProviders) {
+                if (providerMap.containsKey(pv.getProviderNo())) {
+                    filteredProviders.add(pv);
+                }
+            }
+            distinctConsultProviders = filteredProviders;
+        }
+
</code_context>
<issue_to_address>
**🚨 issue (security):** Provider filter options are privacy-aware, but the server-side filter is not enforced against the same constraints.

The dropdown correctly limits visible providers via `providerMap`, but `filterProviderNo` from the request is still passed through to `estConsultationVecByTeam(...)` and the DAO without being checked against `providerMap` (or equivalent site/team constraints). This allows a crafted request with a provider outside the user’s allowed scope to potentially access unauthorized data. Please either (a) validate/reject `filterProviderNo` values that are not in `providerMap`, or (b) enforce the same site/team restrictions directly in the DAO query so authorization is guaranteed server-side.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🧹 Nitpick comments (1)
src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDao.java (1)

77-96: 💤 Low value

Consider adding @since tag for consistency with other methods.

The existing getConsultationDTOs overload (line 61) and getConsultationDTOsByDemographic (line 73) include @since tags. Adding one here would maintain consistency.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDao.java` around
lines 77 - 96, The JavaDoc comment for the getConsultationDTOs method (the
overload that accepts consultantId and filterProviderNo parameters) is missing a
`@since` tag for consistency with the other getConsultationDTOs overload and the
getConsultationDTOsByDemographic method. Add the `@since` tag to the JavaDoc
comment for this method, placing it after the `@return` tag or in the appropriate
location with other documentation tags, using the same version notation as the
other similar methods in the class.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDao.java`:
- Around line 77-96: The JavaDoc comment for the getConsultationDTOs method (the
overload that accepts consultantId and filterProviderNo parameters) is missing a
`@since` tag for consistency with the other getConsultationDTOs overload and the
getConsultationDTOsByDemographic method. Add the `@since` tag to the JavaDoc
comment for this method, placing it after the `@return` tag or in the appropriate
location with other documentation tags, using the same version notation as the
other similar methods in the class.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: acae5517-c97c-4aa2-bc26-50a64d2468c6

📥 Commits

Reviewing files that changed from the base of the PR and between 5f49a01 and 850ee5a.

📒 Files selected for processing (5)
  • src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDao.java
  • src/main/java/ca/openosp/openo/commn/dao/ConsultationRequestDaoImpl.java
  • src/main/java/ca/openosp/openo/encounter/oscarConsultationRequest/pageUtil/EctViewConsultationRequests2Action.java
  • src/main/java/ca/openosp/openo/encounter/oscarConsultationRequest/pageUtil/EctViewConsultationRequestsUtil.java
  • src/main/webapp/oscarEncounter/oscarConsultationRequest/ViewConsultationRequests.jsp

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

2 issues found across 5 files

Confidence score: 3/5

  • In src/main/webapp/oscarEncounter/oscarConsultationRequest/ViewConsultationRequests.jsp, sanitation/reset logic runs only on submit handlers, so native form.submit() paths used by sorting/paging can carry stale hidden filter IDs and page state, leading users to see incorrect filtered or paged results — route all submit paths through the same reset/sanitize function before merging.
  • In src/main/java/ca/openosp/openo/encounter/oscarConsultationRequest/pageUtil/EctViewConsultationRequestsUtil.java, the unused loggedInInfo parameter is low-risk but leaves intent unclear and may miss useful auth/audit context in exception handling — either remove it with caller cleanup or use it explicitly (especially in the catch path) to reduce maintenance risk.

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

@LiamStanziani LiamStanziani left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Looks good to me! thank you.

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.

[Feature]: Consultation table filters

2 participants