WEB-655 feat(clients): filter datatables by client subtype (Person/En…

[shubhamkumar9199]

…tity)

When viewing a client, all registered datatables were displayed as tabs regardless of the client's subtype. This meant a Person client would see Entity-only datatables (e.g., ENTITY_DATA) and vice versa, which is confusing and incorrect.
This change filters the datatable tabs in the Client View based on the client's
Person clients (legalForm.id = 1) only see datatables with entitySubType: 'person'
Entity clients (legalForm.id = 2) only see datatables with entitySubType: 'entity'
Datatables without an entitySubType remain visible for all client types

WEB-655

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• If you have multiple commits please combine them into one commit by squashing them.

• Read and understood the contribution guidelines at web-app/.github/CONTRIBUTING.md.

Summary by CodeRabbit

New Features

• Client view now filters and displays datatables based on client type (person or entity), ensuring users see only relevant information specific to their client classification.

[coderabbitai]

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

A new helper method filters client datatables based on legal form type (individual or entity) and is now invoked during component initialization to display only relevant datatables for each client subtype.

Changes

Cohort / File(s)	Summary
Datatable filtering by legal form src/app/clients/clients-view/clients-view.component.ts	Added import of LegalFormId enum; introduced filterDatatablesByClientSubtype() helper method to filter datatables based on client legal form type; updated constructor to apply filtering during component initialization.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• IOhacker

🚥 Pre-merge checks | ✅ 3

✅ 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 change: filtering datatables by client subtype (Person/Entity). It is concise, specific, and directly related to the primary objective of the pull request.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

src/app/clients/clients-view/clients-view.component.ts (2)

160-163: Guard !legalFormId is falsy-based — 0 would be treated as "missing".

The number type allows 0, which !legalFormId would catch as falsy, returning unfiltered datatables. This is currently safe because legal form IDs start at 1, but a defensive approach would be an explicit null/undefined check:

-    if (!datatables || !legalFormId) {
+    if (!datatables || legalFormId == null) {

Low priority since the API contract makes 0 unlikely.

---

160-166: Make legal form filtering explicit instead of relying on implicit fallback.

Line 164 uses a ternary that silently falls to 'entity' for any value that isn't LegalFormId.PERSON. While the enum currently has only two values (PERSON and ENTITY), if a third legal form is introduced or an unexpected value reaches this method, entity-only datatables would be shown and person-specific ones hidden. Make the logic explicit to handle all known legal forms and fail safely:

Suggested improvement

-    const subtype = legalFormId === LegalFormId.PERSON ? 'person' : 'entity';
-    return datatables.filter((dt: any) => !dt.entitySubType || dt.entitySubType.toLowerCase() === subtype);
+    let subtype: string | null = null;
+    if (legalFormId === LegalFormId.PERSON) {
+      subtype = 'person';
+    } else if (legalFormId === LegalFormId.ENTITY) {
+      subtype = 'entity';
+    }
+    if (!subtype) {
+      return datatables;
+    }
+    return datatables.filter((dt: any) => !dt.entitySubType || dt.entitySubType.toLowerCase() === subtype);

This makes the code self-documenting about which legal forms are supported and prevents silent misfiltering if unexpected values occur.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[IOhacker]

LGTM