Cleanup keycloak logger

[ThomasAFink]

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

• Refactor

  • Standardized the application’s internal identifiers to a unified value and introduced module-specific names for improved consistency.
  • Enhanced logging by incorporating clear module identification.

• Chore

  • Updated ignore rules to cover additional development-related files and directories.
  • Removed an obsolete configuration file to streamline maintenance.

[coderabbitai]

Walkthrough

This pull request standardizes module identifiers across multiple components. In various configuration and application files for modules such as zmsadmin, zmsapi, zmscalldisplay, zmscitizenapi, zmsdb, zmsmessaging, zmsstatistic, and zmsticketprinter, constant values are updated so that identifiers default to 'zms' instead of module-specific strings. Additionally, new constants (e.g. MODULE_NAME or ZMS_MODULE_NAME) are introduced to clearly define each module's name. Minor logging configuration updates and improvements to ignore rules (and the removal of an obsolete config file) are also included.

Changes

File(s)	Change Summary
zmsadmin/config.example.php, zmsapi/config.example.php, zmscalldisplay/config.example.php, zmscitizenapi/config.example.php, zmsdb/config.example.php, zmsmessaging/config.example.php, zmsstatistic/config.example.php, zmsticketprinter/config.example.php	Updated configuration constants: default ZMS_IDENTIFIER now set to 'zms'; added ZMS_MODULE_NAME with each module's name; and updated the App class to define MODULE_NAME accordingly.
zmsadmin/src/.../Application.php, zmsapi/src/.../Application.php, zmscalldisplay/src/.../Application.php, zmscitizenapi/src/.../Application.php, zmsmessaging/src/.../Application.php, zmsstatistic/src/.../Application.php, zmsticketprinter/src/.../Application.php	Modified application classes by updating the IDENTIFIER constant from module-specific strings to 'zms' and adding a new MODULE_NAME constant representing the module name.
zmsslim/src/Slim/Application.php, zmsslim/src/Slim/Bootstrap.php, zmsslim/src/Slim/Middleware/OAuth/KeycloakInstance.php	In the zmsslim module: added a MODULE_NAME constant (set to 'unnamed slim module'); updated logger configuration in Bootstrap (now using 'zms' for application identifier and adding a module key defaulting to 'zmsslim'); and refactored KeycloakInstance to use a static logger reference.
zmsstatistic/.gitignore, zmsstatistic/config.php	Enhanced the .gitignore file with additional entries (e.g., for Composer, IDE configs, cache, logs) and removed the obsolete zmsstatistic/config.php file.

Sequence Diagram(s)

sequenceDiagram
    participant KC as KeycloakInstance
    participant Log as App::$log
    KC->>Log: Log OIDC login failure
    KC->>Log: Log token validation error

Loading

Possibly related PRs

• feat(MPDZBS-877 ZMS-1232 ZMS-2509 ZMS-2510 ZMS-2511 ZMS-2512 ZMS-2513 ZMS-2514 ZMS-2515 ZMS-2516 ZMS-2517 ZMS-2518 ZMS-2519 ZMS-2520 ZMS-2521 ZMS-2523 ZMS-2993): Zmscitizenapi into next #769: Updates configuration constants in zmsadmin/config.example.php that align with module identification and API interaction changes, indicating a strong code-level connection.

Poem

I'm a rabbit in the code forest, swift and free,
Hopping through constants that now agree.
'zms' rings true where once confusion reigned,
And each MODULE_NAME proudly remains.
With a twitch of my nose and a skip so bright,
I celebrate clean code by day and by night! 🥕🐇

✨ 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 plan to trigger planning for file edits and PR creation.
• @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: 0

🔭 Outside diff range comments (1)

zmsslim/src/Slim/Bootstrap.php (1)

209-211: ⚠️ Potential issue

Replace error_log() with proper logging mechanism.

According to the project coding guidelines, error_log() should be replaced with a proper logging framework.

Replace this:

- error_log("Could not write Router-Cache-File: $cacheFile");
+ App::$log->error("Could not write Router-Cache-File", ['file' => $cacheFile]);

This ensures consistent logging across the application and follows the PSR-3 LoggerInterface pattern used elsewhere.

🧹 Nitpick comments (1)

zmsdb/config.example.php (1)

41-45: Consider updating the constant naming for consistency.

The first constant follows a shorter naming convention (IDENTIFIER) while the second one (ZMS_MODULE_NAME) uses the same name as the global constant. For better consistency, consider renaming to either:

const IDENTIFIER = ZMS_IDENTIFIER;
-const ZMS_MODULE_NAME = ZMS_MODULE_NAME;
+const MODULE_NAME = ZMS_MODULE_NAME;

Or:

-const IDENTIFIER = ZMS_IDENTIFIER;
-const ZMS_MODULE_NAME = ZMS_MODULE_NAME;
+const ZMS_IDENTIFIER = ZMS_IDENTIFIER;
+const ZMS_MODULE_NAME = ZMS_MODULE_NAME;

📜 Review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between 64a9b69 and 02ce5b4.

📒 Files selected for processing (20)

• zmsadmin/config.example.php (2 hunks)
• zmsadmin/src/Zmsadmin/Application.php (1 hunks)
• zmsapi/config.example.php (2 hunks)
• zmsapi/src/Zmsapi/Application.php (1 hunks)
• zmscalldisplay/config.example.php (1 hunks)
• zmscalldisplay/src/Zmscalldisplay/Application.php (1 hunks)
• zmscitizenapi/config.example.php (2 hunks)
• zmscitizenapi/src/Zmscitizenapi/Application.php (1 hunks)
• zmsdb/config.example.php (2 hunks)
• zmsmessaging/config.example.php (2 hunks)
• zmsmessaging/src/Zmsmessaging/Application.php (1 hunks)
• zmsslim/src/Slim/Application.php (1 hunks)
• zmsslim/src/Slim/Bootstrap.php (1 hunks)
• zmsslim/src/Slim/Middleware/OAuth/KeycloakInstance.php (8 hunks)
• zmsstatistic/.gitignore (1 hunks)
• zmsstatistic/config.example.php (2 hunks)
• zmsstatistic/config.php (0 hunks)
• zmsstatistic/src/Zmsstatistic/Application.php (1 hunks)
• zmsticketprinter/config.example.php (1 hunks)
• zmsticketprinter/src/Zmsticketprinter/Application.php (1 hunks)

💤 Files with no reviewable changes (1)

• zmsstatistic/config.php

🧰 Additional context used

📓 Path-based instructions (1)

`**/*.php`: Flag any usage of error_log() as it should be replaced with proper logging mechanisms: 1. For error handling: Use a proper logging framework with error levels (PSR-3 Lo...

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

1. For error handling: Use a proper logging framework with error levels (PSR-3 LoggerInterface)
2. For debugging: Use a dedicated debug logger or remove debug statements
3. For CLI output: Use a CLI output handler or symfony/console
4. 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()]);

• zmsslim/src/Slim/Application.php
• zmsstatistic/src/Zmsstatistic/Application.php
• zmsslim/src/Slim/Bootstrap.php
• zmsmessaging/src/Zmsmessaging/Application.php
• zmsticketprinter/src/Zmsticketprinter/Application.php
• zmscitizenapi/src/Zmscitizenapi/Application.php
• zmsticketprinter/config.example.php
• zmsstatistic/config.example.php
• zmscitizenapi/config.example.php
• zmsslim/src/Slim/Middleware/OAuth/KeycloakInstance.php
• zmscalldisplay/config.example.php
• zmsdb/config.example.php
• zmsadmin/config.example.php
• zmscalldisplay/src/Zmscalldisplay/Application.php
• zmsmessaging/config.example.php
• zmsapi/config.example.php
• zmsapi/src/Zmsapi/Application.php
• zmsadmin/src/Zmsadmin/Application.php

🧬 Code Definitions (4)

zmsslim/src/Slim/Bootstrap.php (8)

zmscitizenapi/config.example.php (1)

• App (7-28)

zmsadmin/config.example.php (1)

• App (9-31)

zmscalldisplay/config.example.php (1)

• App (9-28)

zmsapi/config.example.php (1)

• App (51-90)

zmsdb/config.example.php (1)

• App (40-47)

zmsmessaging/config.example.php (1)

• App (25-68)

zmsstatistic/config.example.php (1)

• App (9-31)

zmsticketprinter/config.example.php (1)

• App (9-28)

zmsticketprinter/config.example.php (6)

zmsadmin/config.example.php (1)

• App (9-31)

zmscalldisplay/config.example.php (1)

• App (9-28)

zmsapi/config.example.php (1)

• App (51-90)

zmscitizenapi/config.example.php (1)

• App (7-28)

zmsdb/config.example.php (1)

• App (40-47)

zmsstatistic/config.example.php (1)

• App (9-31)

zmscalldisplay/config.example.php (6)

zmsadmin/config.example.php (1)

• App (9-31)

zmsapi/config.example.php (1)

• App (51-90)

zmscitizenapi/config.example.php (1)

• App (7-28)

zmsdb/config.example.php (1)

• App (40-47)

zmsstatistic/config.example.php (1)

• App (9-31)

zmsticketprinter/config.example.php (1)

• App (9-28)

zmsapi/config.example.php (6)

zmsadmin/config.example.php (1)

• App (9-31)

zmscalldisplay/config.example.php (1)

• App (9-28)

zmscitizenapi/config.example.php (1)

• App (7-28)

zmsdb/config.example.php (1)

• App (40-47)

zmsstatistic/config.example.php (1)

• App (9-31)

zmsticketprinter/config.example.php (1)

• App (9-28)

🔇 Additional comments (38)

zmsslim/src/Slim/Application.php (1)

16-17: Clean addition of module identification constant.

Adding the MODULE_NAME constant provides a clear way to identify modules across the application, which aligns with the standardization efforts seen in other files of this PR.

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

27-29: Standardization of application identifiers.

Good change that establishes consistency across the codebase by:

1. Changing IDENTIFIER to the standardized 'zms' value
2. Adding a MODULE_NAME constant to specifically identify this module as 'zmsadmin'

This aligns with similar changes across other application modules.

zmsslim/src/Slim/Middleware/OAuth/KeycloakInstance.php (10)

57-61: Standardized logging mechanism correctly implemented.

Using the static logger reference \App::$log instead of an instance variable provides consistent logging across the application.

---

106-110: Consistent error logging for token validation failures.

The update properly uses the application-wide logging reference.

---

114-118: Appropriate logging standardization for missing payload errors.

The change follows the same pattern of using the static logger reference.

---

122-126: Uniform logging implementation for signature validation failures.

Consistent with other logging changes in this file.

---

140-145: Standardized error logging for JSON parsing errors.

The change maintains consistency with other logging updates.

---

150-156: Proper error logging for resource access validation.

The standardized approach provides detailed context for troubleshooting.

---

161-167: Consistent logging for app identifier validation.

The update correctly includes the application identifier in the log context.

---

175-181: Standardized error logging for roles validation.

The update follows the established pattern for consistent logging.

---

190-196: Proper error logging for required role validation.

The standardized approach includes helpful context about the missing required role.

---

229-234: Consistent error logging for access token retrieval failures.

The change maintains the pattern of using the static logger reference.

zmsslim/src/Slim/Bootstrap.php (1)

91-93: Improved log structure with separate application and module identifiers.

This change:

1. Standardizes the application identifier to use 'zms' as default
2. Adds a new 'module' field to distinguish between different modules
3. Supports the overall standardization effort across the codebase

This enhances log readability and consistency across different components.

zmsapi/src/Zmsapi/Application.php (1)

15-17: LGTM! The standardization of identifiers improves consistency.

The change from module-specific identifiers to a standardized 'zms' identifier with an additional MODULE_NAME constant for module-specific identification is a good practice. This approach simplifies cross-module communication while preserving module-specific identification where needed.

zmscitizenapi/src/Zmscitizenapi/Application.php (1)

18-19: LGTM! Consistent with the identifier standardization pattern.

The change to use 'zms' as the standard identifier while adding a module-specific MODULE_NAME constant follows the same pattern applied across other modules, ensuring system-wide consistency.

zmsstatistic/.gitignore (1)

22-37: Improved .gitignore organization and coverage.

The additions to the .gitignore file follow best practices by organizing ignored files by category and ensuring common development artifacts (composer files, IDE configurations, cache files, and logs) aren't committed to the repository.

Note: There appears to be some duplication between line 20 (.idea) and line 29 (.idea/), but this doesn't cause functional issues in .gitignore files.

zmsmessaging/config.example.php (2)

12-13: LGTM! Consistent module identification approach.

The added constants follow the standardized approach implemented across other modules, setting ZMS_IDENTIFIER with a default of 'zms' and defining the module-specific name.

---

37-41: LGTM! Properly implements the identifier constants in the App class.

The implementation of IDENTIFIER and MODULE_NAME in the App class correctly references the defined constants and includes appropriate documentation.

zmsdb/config.example.php (1)

9-10: Standardization of module identifiers looks good.

Adding these constants provides a consistent way to identify and configure the module across the codebase.

zmsmessaging/src/Zmsmessaging/Application.php (1)

19-20: Module identifier standardization looks good.

The changes standardize the IDENTIFIER constant to 'zms' across all modules while preserving the specific module identity in the new MODULE_NAME constant. This approach improves consistency throughout the codebase.

zmsticketprinter/src/Zmsticketprinter/Application.php (1)

17-19: Module identifier standardization looks good.

Updating the IDENTIFIER constant to 'zms' and adding the MODULE_NAME constant is consistent with the standardization pattern applied across all modules in this PR.

zmsstatistic/src/Zmsstatistic/Application.php (1)

23-25: Module identifier standardization looks good.

Changing the IDENTIFIER constant to 'zms' and adding the MODULE_NAME constant for the specific module name improves consistency across the codebase.

zmsstatistic/config.example.php (2)

6-7: LGTM! Good standardization of identifiers.

Standardizing identifiers to 'zms' and adding a dedicated module name constant improves consistency across the codebase.

---

21-25: Good addition of module name constant.

Adding the MODULE_NAME constant in the App class provides a proper reference point for module identification.

zmsadmin/config.example.php (2)

6-7: LGTM! Consistent identifier standardization.

This follows the same pattern applied to other modules, standardizing identifiers to 'zms' and adding a specific module name constant.

---

21-25: Good MODULE_NAME constant addition.

Adding this constant creates consistency across modules and provides a clear reference point for module identification.

zmscalldisplay/src/Zmscalldisplay/Application.php (1)

17-18: LGTM! Standardizing application identifiers.

Changing the IDENTIFIER constant to 'zms' and adding a dedicated MODULE_NAME constant maintains consistency with other modules while preserving the ability to identify this specific module.

zmscitizenapi/config.example.php (2)

4-5: LGTM! Consistent identifier standardization.

Following the pattern applied across other modules by standardizing identifiers to 'zms' and adding a specific module name constant.

---

24-27: Good MODULE_NAME constant addition.

Adding this constant creates consistency with other modules and provides a clear reference point for module identification.

zmscalldisplay/config.example.php (3)

6-7: LGTM - New constants for module identification

The addition of ZMS_IDENTIFIER and ZMS_MODULE_NAME constants improves configurability by allowing the identifier to be set via environment variables while providing a default fallback value. This is consistent with the standardization pattern applied across other modules.

---

11-11: LGTM - Updated identifier reference

Updating IDENTIFIER to use the new ZMS_IDENTIFIER constant improves consistency across modules while maintaining configurability through environment variables.

---

17-20: LGTM - Added module name constant

Adding the MODULE_NAME constant with proper documentation provides a clear way to identify the module throughout the application. This follows the standardization pattern implemented across other modules.

zmsticketprinter/config.example.php (3)

6-7: LGTM - New constants for module identification

The addition of ZMS_IDENTIFIER and ZMS_MODULE_NAME constants improves configurability by allowing the identifier to be set via environment variables while providing a default fallback value. This is consistent with the standardization pattern applied across other modules.

---

11-11: LGTM - Updated identifier reference

Updating IDENTIFIER to use the new ZMS_IDENTIFIER constant improves consistency across modules while maintaining configurability through environment variables.

---

17-20: LGTM - Added module name constant

Adding the MODULE_NAME constant with proper documentation provides a clear way to identify the module throughout the application. This follows the standardization pattern implemented across other modules.

zmsapi/config.example.php (3)

48-49: LGTM - New constants for module identification

The addition of ZMS_IDENTIFIER and ZMS_MODULE_NAME constants improves configurability by allowing the identifier to be set via environment variables while providing a default fallback value. This is consistent with the standardization pattern applied across other modules.

---

54-54: LGTM - Updated identifier reference

Updating IDENTIFIER to use the new ZMS_IDENTIFIER constant improves consistency across modules while maintaining configurability through environment variables.

---

83-86: LGTM - Added module name constant

Adding the MODULE_NAME constant with proper documentation provides a clear way to identify the module throughout the application. This follows the standardization pattern implemented across other modules.