Skip to content

WEB-106 Do not offer functionality to a user that is not within her/his rights#2900

Merged
IOhacker merged 1 commit intoopenMF:devfrom
JaySoni1:WEB-106-do-not-offer-functionality-to-a-user-that-is-not-within-her-his-rights
Dec 14, 2025
Merged

WEB-106 Do not offer functionality to a user that is not within her/his rights#2900
IOhacker merged 1 commit intoopenMF:devfrom
JaySoni1:WEB-106-do-not-offer-functionality-to-a-user-that-is-not-within-her-his-rights

Conversation

@JaySoni1
Copy link
Copy Markdown
Contributor

@JaySoni1 JaySoni1 commented Dec 14, 2025

Changes Made :-

-Added permission checks to the top-level toolbar menu (Institution, Accounting, Reports, Admin, Configuration Wizard) using the [mifosxHasPermission]directive.
-Now, only users with the appropriate permissions will see the corresponding menu items.
-Ensured the directive is properly imported and used in the toolbar component.
-This prevents unauthorized users from seeing or accessing restricted functionality from the main navigation.

WEB-106

Summary by CodeRabbit

  • Improvements

    • Toolbar menu items (Institution, Accounting, Reports, Admin, Configuration Wizard) now respect user permissions and display conditionally.
    • Navigation selection fields (offices, staff, centers, groups, clients) now render dynamically based on user permissions.
  • Bug Fixes

    • Popover behavior fixed to avoid attempting to open when there is no valid target, preventing potential UI errors.

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

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Dec 14, 2025

Note

.coderabbit.yaml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)
Validation error: Unrecognized key(s) in object: 'pre_merge_checks'
⚙️ Configuration instructions
  • Please see the configuration documentation for more information.
  • You can also validate your configuration using the online YAML validator.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

Two template files now include permission-based visibility guards using the *mifosxHasPermission directive for specific toolbar links and navigation form fields. Additionally, the toolbar component's showPopover method was hardened with an early return when the target is falsy to avoid calling popoverService.open.

Changes

Cohort / File(s) Summary
Permission-based visibility guards in templates
src/app/core/shell/toolbar/toolbar.component.html, src/app/navigation/navigation.component.html
Added *mifosxHasPermission directives to conditionally render toolbar anchors (Institution, Accounting, Reports, Admin, Configuration Wizard) and navigation select fields (offices, staff, centers, groups, clients) based on corresponding READ_* permissions. No routing, event handling, or form logic changes.
Toolbar popover guard
src/app/core/shell/toolbar/toolbar.component.ts
Added an early-return guard in ToolbarComponent.showPopover to skip calling popoverService.open when target is falsy, preventing invalid popover invocations. No signature changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Review template additions for correct permission keys and placement (*mifosxHasPermission usage).
  • Verify showPopover early-return logic doesn't alter intended UX in edge cases and that target can legitimately be falsy in callers.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main objective of the changeset: adding permission-based visibility controls to prevent users from seeing functionality they don't have rights to access.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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

@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

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
src/app/core/shell/toolbar/toolbar.component.html (1)

44-80: Add permission directives to submenu items that access restricted functionality.

The Accounting (line 122), Reports (line 125), and Admin (line 128) buttons in institutionMenu lack permission directives, while the corresponding toolbar links are protected. A user without READ_ACCOUNTING permission will not see the toolbar link but can still navigate to /accounting via the Institution menu, inconsistent with the security model.

Add *mifosxHasPermission to these button elements:

  <button mat-menu-item [routerLink]="['/accounting']" tabindex="0">
+   *mifosxHasPermission="'READ_ACCOUNTING'"
    {{ 'labels.menus.Accounting' | translate }}
  </button>
  <button mat-menu-item [matMenuTriggerFor]="reportsMenu" tabindex="0">
+   *mifosxHasPermission="'READ_REPORTS'"
    {{ 'labels.menus.Reports' | translate }}
  </button>
  <button mat-menu-item [matMenuTriggerFor]="adminMenu" tabindex="0">
+   *mifosxHasPermission="'READ_ADMIN'"
    {{ 'labels.menus.Admin' | translate }}
  </button>

Also apply permission checks to all menu items in reportsMenu and adminMenu for consistent protection throughout the navigation hierarchy.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5a21f3b and 9ad6825.

📒 Files selected for processing (2)
  • src/app/core/shell/toolbar/toolbar.component.html (1 hunks)
  • src/app/navigation/navigation.component.html (5 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/shell/toolbar/toolbar.component.html
  • src/app/navigation/navigation.component.html
🔇 Additional comments (2)
src/app/navigation/navigation.component.html (1)

7-7: Permission guards properly applied to form field visibility.

Each select field is correctly gated with the appropriate *mifosxHasPermission directive, paired with data existence checks. The use of track in @for loops meets performance requirements.

Also applies to: 20-20, 33-33, 46-46, 59-59

src/app/core/shell/toolbar/toolbar.component.html (1)

37-37: Institution permission guard correctly applied.

The Institution menu anchor is properly gated with *mifosxHasPermission="'READ_INSTITUTION'".

Comment thread src/app/core/shell/toolbar/toolbar.component.html
@JaySoni1 JaySoni1 force-pushed the WEB-106-do-not-offer-functionality-to-a-user-that-is-not-within-her-his-rights branch from 9ad6825 to 8845339 Compare December 14, 2025 18:45
Copy link
Copy Markdown

@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)
src/app/core/shell/toolbar/toolbar.component.ts (1)

159-164: Good defensive guard; consider normalizing ElementRef to nativeElement (and guard template) before opening.
Right now !target is handled, but ElementRef with a missing nativeElement would still flow through, and template can also be null-ish in some edge cases.

-  showPopover(template: TemplateRef<any>, target: ElementRef<any> | HTMLElement): void {
-    if (!target) {
-      return;
-    }
-    setTimeout(() => this.popoverService.open(template, target, 'bottom', true, {}), 200);
-  }
+  showPopover(
+    template: TemplateRef<any> | null | undefined,
+    target: ElementRef<HTMLElement> | HTMLElement | null | undefined
+  ): void {
+    if (!template || !target) return;
+    const host = target instanceof ElementRef ? target.nativeElement : target;
+    if (!host) return;
+    window.setTimeout(() => this.popoverService.open(template, host, 'bottom', true, {}), 200);
+  }
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9ad6825 and 8845339.

📒 Files selected for processing (3)
  • src/app/core/shell/toolbar/toolbar.component.html (1 hunks)
  • src/app/core/shell/toolbar/toolbar.component.ts (1 hunks)
  • src/app/navigation/navigation.component.html (5 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/app/navigation/navigation.component.html
  • src/app/core/shell/toolbar/toolbar.component.html
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/shell/toolbar/toolbar.component.ts

Copy link
Copy Markdown
Contributor

@IOhacker IOhacker left a comment

Choose a reason for hiding this comment

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

Lgtm

@IOhacker IOhacker merged commit 6ef7306 into openMF:dev Dec 14, 2025
3 checks passed
@IOhacker
Copy link
Copy Markdown
Contributor

This must be extended to another submenus or pages

@JaySoni1
Copy link
Copy Markdown
Contributor Author

@IOhacker Ok I will create a JIRA ticket for the same .
Thank You for the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants