fix(ZMS-3253 ZMS-3466 ZMS-3415 ZMS-1891): Replicate frontend validation in the backend for the availability opening hours to improve data integrity and frontend validation messaging #909

ThomasAFink · 2025-02-27T15:06:31Z

Pull Request Checklist (Feature Branch to `next`):

Ich habe die neuesten Änderungen aus dem next Branch in meinen Feature-Branch gemergt.
Das Code-Review wurde abgeschlossen.
Fachliche Tests wurden durchgeführt und sind abgeschlossen.

Summary by CodeRabbit

New Features
- Enhanced scheduling with detailed, formatted conflict messages and clearer error alerts.
- Updated date picker now prevents selection during maintenance hours and uses refined time ranges.
- Introduced new sorting options in schedule views and a dedicated view for location-specific availability.
Bug Fixes
- Adjusted appointment slot duration from 12 to 10 minutes.
- Refined button states and form error handling to improve user feedback.
Tests
- Expanded test scenarios covering overlapping schedules, conflict detection, and validation.

…orm error messaging

This reverts commit ce5d795.

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

…ening-hours-of-the-same-appointment-type-must-not-overlap # Conflicts: # zmsadmin/src/Zmsadmin/AvailabilityConflicts.php # zmsapi/src/Zmsapi/AvailabilityUpdate.php # zmsentities/src/Zmsentities/Availability.php

…lityAdd

…ening-hours-of-the-same-appointment-type-must-not-overlap

…ening-hours-of-the-same-appointment-type-must-not-overlap # Conflicts: # zmscalldisplay/package-lock.json

…alidation

…ening-hours-of-the-same-appointment-type-must-not-overlap

coderabbitai · 2025-02-27T15:06:42Z

Walkthrough

This pull request makes extensive updates across both the front‐end and back‐end availability management systems. On the client side, conflict aggregation and rendering, error handling, and UI state management in the availability form and layouts have been revised, including new sorting and disabling logic. On the server side, routing definitions, input validation, conflict processing, and availability add/update endpoints have been refactored with additional modular methods and new exception classes. Tests, fixtures, and schemas have been updated accordingly, notably reducing the slot time from 12 to 10 minutes and adding a new availability “kind” property.

Changes

File(s)	Change Summary
`zmsadmin/js/page/availabilityDay/form/{conflicts,content,datepicker,errors,footerButtons,formButtons,index}.js`	Improved conflict aggregation/display, enhanced error handling, and updated state logic in form elements (with new input disabling conditions and refined date handling).
`zmsadmin/js/page/availabilityDay/layouts/{accordion,page,tableBody,saveBar}.js`	Enhanced layout components with sorting features, duplicate rendering in page layout, and UI adjustments; integration of new props and state management for error display.
`zmsadmin/js/page/availabilityDay/timetable/{graphview,index,scopeview}.js`	Removed outdated footer renderings, introduced a new `ScopeView` component for scope-specific availability display, and streamlined timetable rendering.
`zmsadmin/js/page/availabilityDay/helpers.js`	Enhanced state management by accepting additional parameters and adding functions for time rounding and dynamic availability calculations.
`zmsadmin/js/page/availabilityDay/validate.js`	Expanded validation logic with modular functions for null checks, time format validation, weekday selection, and bookable day range verification.
`zmsadmin/routing.php`	Added a new route for retrieving availability by scope and reformatted existing route definitions for consistent spacing and clarity.
`zmsapi/src/Zmsapi/{AvailabilityAdd,AvailabilityUpdate,Exception/*}.php`	Refactored add/update flows to include comprehensive input validation, modular conflict checking, and improved error handling with new specific exceptions (e.g., `AvailabilityAddFailed`).
`zmsentities/{schema/{availability.json,dereferenced/availability.json,appointment.json},src/Zmsentities/{Availability,Collection/AvailabilityList}.php}`	Reduced `slotTimeInMinutes` from 12 to 10, added a new `"kind"` property to the schema, and introduced additional validation methods and conflict-checking functionality in the Availability entity and its collection.
`zmsadmin/tests/{Zmsadmin/,fixtures/}` and `zmsdb/tests/*`	Updated fixtures and test suites to align with new slot durations, enhanced conflict scenarios, and detailed assertions (including changes in expected timings and additional edge case tests).
`zmsdb/src/Zmsdb/Process.php`	Modified conflict detection by replacing a generic conflict retrieval call with a method specifically checking against existing availabilities.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant AvailabilityPage
    participant API
    participant SaveBar

    User->>AvailabilityPage: Initiate availability update
    AvailabilityPage->>API: POST /availability/save/{id} with payload
    API-->>AvailabilityPage: Return update confirmation
    AvailabilityPage->>SaveBar: updateSaveBarState(type, success)
    SaveBar-->>User: Display success/error message

sequenceDiagram
    participant Form
    participant ConflictModule
    participant Validator

    Form->>ConflictModule: Call renderConflictList()
    ConflictModule->>Validator: Check for existing conflict entries
    Validator-->>ConflictModule: Return conflict details with dates
    ConflictModule-->>Form: Render conflict messages with formatted <br /> tags

Possibly related PRs

fix(ZMS-3253 ZMS-3466 ZMS-3415 ZMS-1891): Replicate frontend validation in the backend for the availability opening hours to improve data integrity and frontend validation messaging #825: Modifies renderConflictList in conflicts.js, aligning with similar conflict handling enhancements in this pull request.

Suggested reviewers

manjencic

Poem

I’m a rabbit, hopping fast,
In fields of code that just came to pass.
Conflicts are sorted and errors tamed,
New routes and updates proudly named.
With each new line, I bounce with glee—
Hoppy changes for all to see! 🐇
CodeRabbit Inc. cheers in harmony!

✨ Finishing Touches

📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

coderabbitai

Actionable comments posted: 2

🧹 Nitpick comments (34)

zmsapi/src/Zmsapi/Exception/Availability/AvailabilityAddFailed.php (1)
5-7: Documentation could be improved for clearer purpose

The documentation comment is quite generic and doesn't explain the specific purpose of this exception class.
-/**
- * example class to generate an exception
- */
+/**
+ * Exception thrown when a new availability creation fails, typically due to conflicts
+ * with existing availability entries.
+ */
zmsadmin/js/page/availabilityDay/form/index.js (1)
46-50: New error detection logic improves validation workflow.

The added hasErrors constant provides a clear way to determine if there are any validation errors present.

Consider simplifying the ternary expression by directly using the boolean evaluation:
-const hasErrors = (
-    (
-        this.props.errorList &&
-        Object.keys(this.props.errorList).length
-    )) ? true : false
+const hasErrors = !!(this.props.errorList && Object.keys(this.props.errorList).length)
🧰 Tools

🪛 Biome (1.9.4)

[error] 46-50: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)
zmsadmin/js/page/availabilityDay/layouts/accordion.js (1)
172-172: Simplify boolean expression

The ternary operator here is unnecessary since you're already returning a boolean value.
-                        hasConflicts={Object.keys(this.props.conflictList.itemList).length ? true : false}
+                        hasConflicts={Object.keys(this.props.conflictList.itemList).length > 0}
🧰 Tools

🪛 Biome (1.9.4)

[error] 172-172: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)
zmsadmin/js/page/availabilityDay/layouts/tableBody.js (2)
214-214: Use optional chaining

Use optional chaining for safer property access.
-                    <td>{availabilityType && availabilityType.name ? availabilityType.name : ""}</td>
+                    <td>{availabilityType?.name || ""}</td>
🧰 Tools

🪛 Biome (1.9.4)

[error] 214-214: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

89-118: Consider extracting sortable column header to a component

The table headers contain repeated code for each sortable column. Consider extracting this pattern to a reusable component to improve maintainability.
zmsadmin/js/page/availabilityDay/form/content.js (3)
24-24: Address the unnecessary use of boolean literals in calenderDisabled.
Static analysis flagged the ternary expression data.type && data.slotTimeInMinutes ? false : true. This can be simplified to:
-const calenderDisabled = data.type && data.slotTimeInMinutes ? false : true;
+const calenderDisabled = !(data.type && data.slotTimeInMinutes);
🧰 Tools

🪛 Biome (1.9.4)

[error] 24-24: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)

41-68: Consider extracting the “unsafedSpontaneous” section into a reusable component.
The code block providing guidance for unsaved spontaneous openings is fairly large. Extracting it into a dedicated component (e.g., UnsafedSpontaneousNotice) could reduce clutter in this file.

163-165: Avoid potential confusion with repeated inline forms.
Multiple FormGroup elements within the “Terminabstand” section are correct for user input clarity, but consider grouping them if potential expansions or conditionals arise. This fosters better maintainability.

Also applies to: 173-173, 176-176, 178-179
zmsadmin/js/page/availabilityDay/saveBar.js (1)

25-35: Refine or localize the user feedback strings.
The getMessage() function uses string literals for success/error messages. Consider localizing them if i18n is required, or ensuring consistent capitalization and styling across the app.
zmsapi/tests/Zmsapi/AvailabilityUpdateTest.php (2)
97-105: Mismatch between comment and actual offset.
Line 102 says “// 2 days in the future” yet uses (20 * 24 * 60 * 60). Correct the comment to avoid confusion.

Apply this small fix:
-// 2 days in the future
+// 20 days in the future
110-112: Similarly correct the day offset in the dayoff array.
The code uses (70 * 24 * 60 * 60) but the comment says “7 days in the future.” Ensure the comment is updated appropriately.
zmsadmin/src/Zmsadmin/AvailabilityListByScope.php (2)

31-33: Consider adding stricter date format validation.
While isString() ensures the parameters are strings, there is no guarantee they represent valid dates (e.g., "abc" would pass). You could enhance data integrity by verifying they match an expected date format.

58-63: Refine exception handling for missing availability data.
Matching by string comparison on $exception->template may be brittle if exception classes or messages change. Consider catching a more specific exception class or applying an internal code property to streamline error handling and reduce the risk of false matches.

zmsadmin/js/page/availabilityDay/form/footerButtons.js (1)

47-73: Simplify the complex disabled conditions.
Buttons have lengthy inline conditions that can impact readability and maintenance. Consider extracting them to well-named helper variables or a small function.

zmsapi/src/Zmsapi/AvailabilityAdd.php (4)

43-52: Suggestion: Provide a clearer error message.
While the validation logic here is correct, throwing a generic BadRequestException without a descriptive message may hamper debugging. A short message (e.g., "Invalid or empty input JSON") could help users quickly identify the issue.

67-70: Clarify default resolveReferences behavior.
Defaulting resolveReferences to 2 might be contextually correct, but consider a descriptive constant (e.g., const DEFAULT_RESOLVE_REFERENCES = 2) or inline comment to clarify its meaning.

102-125: Conflict filtering strategy is well-structured.
Thanks to dedicated methods (getInitialConflicts, getMergedCollection, validateNewAvailabilities, etc.), the conflict detection logic is simpler to follow. If users need more context when AvailabilityAddFailed is thrown, consider passing relevant info (e.g., conflict details) to the exception.

329-348: Extended update logic with $resolveReferences.
Allows for flexible entity resolution. For further clarity, unify your exception messages for missing entities (line 339) or add additional context to help identify which records failed.

zmsadmin/js/page/availabilityDay/helpers.js (2)

83-93: Time-rounding utility – roundToSlotBoundary.
Separating slot increments for 5 and 10 minutes is workable, though consider making the permissible increments more flexible for potential future changes (e.g., 15 minutes). Otherwise, good approach.

94-195: getNewAvailability robustly calculates default times.
You gather existing availabilities, calculate start/end times, and avoid overlaps. This is an elegant solution for auto-populating a new availability slot. Keep an eye on performance if the list of existing availabilities grows large; a more optimized search approach may eventually be needed.
zmsadmin/js/page/availabilityDay/form/validate.js (1)
30-30: Simplify the boolean assignment.

At line 30, the use of a ternary operator is unnecessary. You can directly assign a boolean by checking whether errorList.itemList.length is zero:
-  let valid = (0 < errorList.itemList.length) ? false : true;
+  let valid = (errorList.itemList.length === 0);
🧰 Tools

🪛 Biome (1.9.4)

[error] 30-30: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)
zmsadmin/tests/Zmsadmin/AvailabilityConflictsTest.php (1)

1977-2485: Potential for data provider usage to reduce duplication.

Some test entries appear repetitively in multiple methods. Introducing dedicated data providers or fixture references might simplify maintenance and reduce code duplication in the future.
zmsadmin/js/page/availabilityDay/index.js (3)
153-153: Consider optional chaining.

Where you have:
(availability.tempId && availability.tempId.includes('__temp__'))
you could simplify with optional chaining if allowed:
- if (availability.tempId && availability.tempId.includes('__temp__')) {
+ if (availability.tempId?.includes('__temp__')) {
🧰 Tools

🪛 Biome (1.9.4)

[error] 153-153: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

160-161: Avoid performance overhead from the delete operator.

The delete operator can introduce engine de-optimizations. Consider setting the property to undefined instead for better performance:
- delete sendAvailability.tempId;
+ sendAvailability.tempId = undefined;
🧰 Tools

🪛 Biome (1.9.4)

[error] 160-161: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

238-239: Apply the same fix for delete here as well.

Just like above, replace:
- delete sendAvailability.tempId;
+ sendAvailability.tempId = undefined;
to maintain consistency and avoid performance pitfalls.

🧰 Tools

🪛 Biome (1.9.4)

[error] 238-239: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)
zmsentities/src/Zmsentities/Collection/AvailabilityList.php (3)

182-194: Aggregates validation from each Availability.

The merge approach is effective, but watch out for potential duplicates in $errorList if you plan to handle them distinctly.

341-370: checkForConflictsWithExistingAvailabilities.

Iterating day by day can be performance-intensive for large ranges. Possibly consider a more direct approach if performance becomes an issue.

372-417: findOverlapsOnDate.

Useful decomposition. The daily approach is simple to follow but might be suboptimal for extensive date ranges. Consider future improvements if needed.

zmsadmin/src/Zmsadmin/AvailabilityConflicts.php (1)

143-205: filterAndSortConflicts.

Groups conflicts by day, sorts them, and forms a new structure for the front end. This is a big chunk. Consider further extracting the day-group logic or adopting a specialized data structure.

zmsentities/src/Zmsentities/Availability.php (3)

116-116: Docblock type hint
The docblock suggests $type is always a string, but the code also accepts false. Consider updating the declaration to string|bool for accuracy.

141-141: Docblock type consistency
Same consideration as line 116: include bool in the docblock to reflect possible false values.

458-497: Potential code reuse
These time-of-day checks (22:00–01:00) may appear in other validation methods. Consider extracting common validation logic into a helper.

zmsadmin/routing.php (2)

24-25: AvailabilityDelete
Uses GET to delete availability. Typically, DELETE or POST would be more RESTful. Verify if this is intentional.

280-280: ProcessDelete
Again, uses GET to delete a resource. Consider changing it to POST or DELETE for consistency.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 09f57f6 and 7e98a91.

⛔ Files ignored due to path filters (1)

zmsadmin/src/Zmsadmin/debug.log is excluded by !**/*.log

📒 Files selected for processing (45)

zmsadmin/js/page/availabilityDay/form/conflicts.js (1 hunks)
zmsadmin/js/page/availabilityDay/form/content.js (5 hunks)
zmsadmin/js/page/availabilityDay/form/datepicker.js (10 hunks)
zmsadmin/js/page/availabilityDay/form/errors.js (2 hunks)
zmsadmin/js/page/availabilityDay/form/footerButtons.js (1 hunks)
zmsadmin/js/page/availabilityDay/form/formButtons.js (3 hunks)
zmsadmin/js/page/availabilityDay/form/index.js (2 hunks)
zmsadmin/js/page/availabilityDay/form/validate.js (5 hunks)
zmsadmin/js/page/availabilityDay/helpers.js (7 hunks)
zmsadmin/js/page/availabilityDay/index.js (21 hunks)
zmsadmin/js/page/availabilityDay/layouts/accordion.js (6 hunks)
zmsadmin/js/page/availabilityDay/layouts/page.js (2 hunks)
zmsadmin/js/page/availabilityDay/layouts/tableBody.js (5 hunks)
zmsadmin/js/page/availabilityDay/saveBar.js (1 hunks)
zmsadmin/js/page/availabilityDay/timetable/graphview.js (0 hunks)
zmsadmin/js/page/availabilityDay/timetable/index.js (1 hunks)
zmsadmin/js/page/availabilityDay/timetable/scopeview.js (1 hunks)
zmsadmin/routing.php (16 hunks)
zmsadmin/src/Zmsadmin/AvailabilityConflicts.php (3 hunks)
zmsadmin/src/Zmsadmin/AvailabilityListByScope.php (1 hunks)
zmsadmin/templates/exception/bo/zmsapi/exception/availability/availabilityaddfailed.twig (1 hunks)
zmsadmin/templates/exception/bo/zmsapi/exception/availability/availabilityupdatefailed.twig (1 hunks)
zmsadmin/templates/page/availabilityday.twig (1 hunks)
zmsadmin/tests/Zmsadmin/AvailabilityConflictsTest.php (6 hunks)
zmsadmin/tests/Zmsadmin/fixtures/GET_Workstation_Resolved2.json (1 hunks)
zmsadmin/tests/Zmsadmin/fixtures/GET_Workstation_scope_141_multipleSlotsEnabled.json (1 hunks)
zmsadmin/tests/Zmsadmin/fixtures/GET_scope_141.json (1 hunks)
zmsadmin/tests/Zmsadmin/fixtures/GET_scope_141_multipleSlotsEnabled.json (1 hunks)
zmsadmin/tests/Zmsadmin/fixtures/GET_scope_list.json (1 hunks)
zmsapi/src/Zmsapi/AvailabilityAdd.php (1 hunks)
zmsapi/src/Zmsapi/AvailabilityUpdate.php (1 hunks)
zmsapi/src/Zmsapi/Exception/Availability/AvailabilityAddFailed.php (1 hunks)
zmsapi/src/Zmsapi/Exception/Availability/AvailabilityUpdateFailed.php (1 hunks)
zmsapi/tests/Zmsapi/AvailabilityAddTest.php (2 hunks)
zmsapi/tests/Zmsapi/AvailabilityUpdateTest.php (3 hunks)
zmsdb/src/Zmsdb/Process.php (1 hunks)
zmsdb/tests/Zmsdb/AvailabilityTest.php (1 hunks)
zmsdb/tests/Zmsdb/ProcessConflictTest.php (3 hunks)
zmsentities/schema/availability.json (2 hunks)
zmsentities/schema/dereferenced/appointment.json (1 hunks)
zmsentities/schema/dereferenced/availability.json (1 hunks)
zmsentities/src/Zmsentities/Availability.php (11 hunks)
zmsentities/src/Zmsentities/Collection/AvailabilityList.php (5 hunks)
zmsentities/tests/Zmsentities/AvailabilityTest.php (8 hunks)
zmsentities/tests/Zmsentities/ProcessTest.php (1 hunks)

💤 Files with no reviewable changes (1)

zmsadmin/js/page/availabilityDay/timetable/graphview.js

✅ Files skipped from review due to trivial changes (4)

zmsadmin/templates/exception/bo/zmsapi/exception/availability/availabilityaddfailed.twig
zmsadmin/templates/exception/bo/zmsapi/exception/availability/availabilityupdatefailed.twig
zmsadmin/templates/page/availabilityday.twig
zmsapi/src/Zmsapi/Exception/Availability/AvailabilityUpdateFailed.php

🧰 Additional context used

📓 Path-based instructions (2)

`**/*.php`: Flag any usage of error_log() as it should be re...

**/*.php: Flag any usage of error_log() as it should be replaced with proper logging mechanisms:

For error handling: Use a proper logging framework with error levels (PSR-3 LoggerInterface)

For debugging: Use a dedicated debug logger or remove debug statements

For CLI output: Use a CLI output handler or symfony/console

For application events: Use structured logging with proper log levels

Example replacement:
// Instead of:
error_log("Import failed - " . $e->getMessage());

// Use:
$logger->error("Import failed", ['error' => $e->getMessage()]);

zmsdb/tests/Zmsdb/AvailabilityTest.php
zmsapi/src/Zmsapi/Exception/Availability/AvailabilityAddFailed.php
zmsdb/src/Zmsdb/Process.php
zmsdb/tests/Zmsdb/ProcessConflictTest.php
zmsadmin/src/Zmsadmin/AvailabilityListByScope.php
zmsapi/tests/Zmsapi/AvailabilityAddTest.php
zmsentities/tests/Zmsentities/ProcessTest.php
zmsentities/src/Zmsentities/Collection/AvailabilityList.php
zmsapi/tests/Zmsapi/AvailabilityUpdateTest.php
zmsadmin/src/Zmsadmin/AvailabilityConflicts.php
zmsentities/src/Zmsentities/Availability.php
zmsentities/tests/Zmsentities/AvailabilityTest.php
zmsapi/src/Zmsapi/AvailabilityAdd.php
zmsapi/src/Zmsapi/AvailabilityUpdate.php
zmsadmin/tests/Zmsadmin/AvailabilityConflictsTest.php
zmsadmin/routing.php

`**/*.{js,jsx,ts,tsx}`: Flag any usage of console.log() as i...

**/*.{js,jsx,ts,tsx}: Flag any usage of console.log() as it should be replaced with proper logging:

For development: Use proper debug tools or logging libraries

For production: Remove console.log() statements or use structured logging

For errors: Use error tracking services (e.g., Sentry)

For debugging: Consider using debug libraries that can be enabled/disabled

Example replacement:
// Instead of:
console.log('User data:', userData);

// Use:
logger.debug('Processing user data', { userData });
// or for development only:
if (process.env.NODE_ENV === 'development') {
  debug('User data:', userData);
}

zmsadmin/js/page/availabilityDay/timetable/index.js
zmsadmin/js/page/availabilityDay/layouts/page.js
zmsadmin/js/page/availabilityDay/form/index.js
zmsadmin/js/page/availabilityDay/form/errors.js
zmsadmin/js/page/availabilityDay/timetable/scopeview.js
zmsadmin/js/page/availabilityDay/form/conflicts.js
zmsadmin/js/page/availabilityDay/form/content.js
zmsadmin/js/page/availabilityDay/layouts/accordion.js
zmsadmin/js/page/availabilityDay/layouts/tableBody.js
zmsadmin/js/page/availabilityDay/form/footerButtons.js
zmsadmin/js/page/availabilityDay/form/datepicker.js
zmsadmin/js/page/availabilityDay/form/formButtons.js
zmsadmin/js/page/availabilityDay/helpers.js
zmsadmin/js/page/availabilityDay/index.js
zmsadmin/js/page/availabilityDay/form/validate.js
zmsadmin/js/page/availabilityDay/saveBar.js

🧠 Learnings (4)

zmsadmin/js/page/availabilityDay/layouts/page.js (1)

Learnt from: ThomasAFink
PR: it-at-m/eappointment#685
File: zmsadmin/js/page/availabilityDay/layouts/page.js:14-14
Timestamp: 2024-12-04T12:18:56.123Z
Learning: In `zmsadmin/js/page/availabilityDay/layouts/page.js`, it's acceptable to render the `saveBar` component twice, once after `props.timeTable` and once after `props.accordion`, to display the save bar at both the top and bottom of the layout.

zmsadmin/js/page/availabilityDay/index.js (2)

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-01-30T15:35:15.938Z
Learning: In the eappointment system's handleChange method, when validating form changes, run getValidationList and getConflictList in parallel using Promise.all, and only proceed with readCalculatedAvailabilityList after both validations complete to avoid race conditions.

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-01-27T16:54:44.665Z
Learning: In the eappointment system's getConflictList method, create a copy of selectedAvailability before modifying it to avoid mutating state directly, handle null selectedAvailability gracefully, clear stale conflicts on errors, and maintain a consistent promise chain to ensure proper button state management.

zmsadmin/src/Zmsadmin/AvailabilityConflicts.php (3)

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-02-17T09:47:44.330Z
Learning: The getAvailabilityData() method in AvailabilityConflicts.php should be refactored into smaller methods: validateInput(), processAvailabilityKinds(), getConflictList(), and filterAndSortConflicts() to improve maintainability and reduce complexity.

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-02-17T09:49:29.414Z
Learning: The getAvailabilityData() method in AvailabilityConflicts.php should be refactored to reduce complexity by:
1. Extracting validation logic into separate methods
2. Breaking down availability kind processing
3. Isolating conflict filtering logic
4. Moving sorting to dedicated methods
5. Using early returns to avoid nested conditions

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-02-17T09:44:29.822Z
Learning: The `getAvailabilityData` method in `AvailabilityConflicts` class should be refactored to reduce complexity by:
1. Extracting validation logic into separate methods
2. Breaking down availability kind processing
3. Isolating conflict filtering logic
4. Moving sorting to dedicated methods
5. Using early returns to avoid nested conditions

zmsapi/src/Zmsapi/AvailabilityAdd.php (2)

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-02-17T10:13:48.667Z
Learning: The readResponse() method in AvailabilityAdd.php should be refactored to reduce complexity by:
1. Separating input validation into dedicated methods
2. Breaking down collection processing logic
3. Isolating conflict detection and filtering
4. Moving entity update logic to separate methods
5. Using type hints for better code clarity

Learnt from: ThomasAFink
PR: it-at-m/eappointment#0
File: :0-0
Timestamp: 2025-02-17T10:19:41.023Z
Learning: The readResponse() method in AvailabilityUpdate.php should be refactored to reduce complexity by:
1. Separating input validation into dedicated methods
2. Breaking down collection processing logic
3. Isolating conflict detection and filtering
4. Moving entity update logic to separate methods
5. Using type hints for better code clarity

🪛 Biome (1.9.4)

zmsadmin/js/page/availabilityDay/form/index.js

[error] 46-50: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)

zmsadmin/js/page/availabilityDay/form/conflicts.js

[error] 33-33: Avoid passing content using the dangerouslySetInnerHTML prop.

Setting content using code can expose users to cross-site scripting (XSS) attacks

(lint/security/noDangerouslySetInnerHtml)

zmsadmin/js/page/availabilityDay/form/content.js

[error] 24-24: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)

zmsadmin/js/page/availabilityDay/layouts/accordion.js

[error] 172-172: Unnecessary use of boolean literals in conditional expression.

Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with

(lint/complexity/noUselessTernary)

zmsadmin/js/page/availabilityDay/layouts/tableBody.js

[error] 38-38: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.

The declaration is defined in this switch clause:

Unsafe fix: Wrap the declaration in a block.