Fix/4183/user settings in wrong area

[EthanJappie]

User settings should not be visible under General Settings list

Summary by CodeRabbit

• New Features
  • The settings editor now supports marking configuration items as user-specific or application-wide, providing better organization of settings based on scope.
  • Enhanced filtering logic ensures user-specific settings are properly excluded from general settings views when no application context is selected, improving the settings discovery and management experience.

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

[coderabbitai]

Walkthrough

This change adds a boolean isUserSpecific property to the SettingConfiguration data model, propagates it through the provider's fetch and mapping logic, and updates the settings menu display condition to exclude user-specific settings when no application context is selected.

Changes

Cohort / File(s)	Summary
SettingConfiguration model updates shesha-reactjs/src/components/settingsEditor/provider/models.ts, shesha-reactjs/src/components/settingsEditor/provider/index.tsx	Added isUserSpecific: boolean property to the ISettingConfiguration interface. Updated the SettingConfigurationDto to include the same property, added it to the GraphQL fetch parameters string, and mapped it from the DTO to the configuration object.
Settings menu display logic shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx	Tightened the condition for displaying non-client-specific settings to also exclude user-specific settings when no application is selected.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Review the isUserSpecific property flow through the data layer to ensure consistent mapping and no type mismatches
• Verify the updated filtering logic in settingsMenu.tsx correctly applies the new user-specific condition

Possibly related PRs

• fixed settings editor #3902 — Modifies the same SettingConfiguration DTO and GetAll query properties in the settings editor provider, suggesting coordinated updates to the configuration model.

Suggested reviewers

• James-Baloyi
• AlexStepantsov

Poem

🐰 A bunny hops through settings fair,
Where user-specific flags now care,
No app? No problem! Skip the user's own,
Each config finds its rightful home! ✨

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 'Fix/4183/user settings in wrong area' directly relates to the main change: excluding user-specific settings from the general settings list by adding isUserSpecific flag and filtering logic.
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

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4b39ed4 and e243efb.

📒 Files selected for processing (3)

• shesha-reactjs/src/components/settingsEditor/provider/index.tsx (3 hunks)
• shesha-reactjs/src/components/settingsEditor/provider/models.ts (1 hunks)
• shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{ts,tsx}

📄 CodeRabbit inference engine (CodeRabbitReview-Project-Specific-Guidelines.md)

**/*.{ts,tsx}: Eliminate the any type; use unknown type instead for values with unknown types, forcing explicit type checking
Prefer type guards over type casting for type checking
Avoid monolithic types; use discriminated unions with a discriminator property instead
Leverage TypeScript to its full potential as a type system, not merely as a linter

Files:

• shesha-reactjs/src/components/settingsEditor/provider/models.ts
• shesha-reactjs/src/components/settingsEditor/provider/index.tsx
• shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx

🧠 Learnings (5)

📚 Learning: 2025-11-20T14:51:46.152Z

Learnt from: AlexStepantsov
Repo: shesha-io/shesha-framework PR: 4235
File: shesha-reactjs/src/components/modelConfigurator/propertiesEditor/provider/reducer.ts:149-149
Timestamp: 2025-11-20T14:51:46.152Z
Learning: In shesha-reactjs model configurator reducer (src/components/modelConfigurator/propertiesEditor/provider/reducer.ts), when handling ArrayFormats.childObjects in the UpdateItem action, itemsType.dataFormat should be set to undefined (not ObjectFormats.object). This is the correct logic for child object array configuration.

Applied to files:

• shesha-reactjs/src/components/settingsEditor/provider/models.ts
• shesha-reactjs/src/components/settingsEditor/provider/index.tsx
• shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx

📚 Learning: 2025-06-26T20:01:48.838Z

Learnt from: teboho
Repo: shesha-io/shesha-framework PR: 3461
File: shesha-reactjs/src/designer-components/charts/settingsFormIndividual.ts:171-192
Timestamp: 2025-06-26T20:01:48.838Z
Learning: In shesha-reactjs chart settings forms, duplicate input configurations may be intentionally included as part of UI/UX experiments and should be flagged for review during UI/UX review phases rather than immediately removed as errors.

Applied to files:

• shesha-reactjs/src/components/settingsEditor/provider/models.ts
• shesha-reactjs/src/components/settingsEditor/provider/index.tsx
• shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx

📚 Learning: 2025-06-12T16:55:57.638Z

Learnt from: teboho
Repo: shesha-io/shesha-framework PR: 3397
File: shesha-reactjs/src/designer-components/charts/bar.tsx:49-52
Timestamp: 2025-06-12T16:55:57.638Z
Learning: For the chart components’ migrators (e.g., BarChartComponent in shesha-reactjs/src/designer-components/charts/bar.tsx), the version 5 step intentionally spreads `{ ...prev, ...defaultConfigFiller }` so that values from `defaultConfigFiller` override any existing properties in `prev`. This reset to new defaults is by design and should not be flagged as an issue.

Applied to files:

• shesha-reactjs/src/components/settingsEditor/provider/index.tsx

📚 Learning: 2025-11-05T07:46:22.081Z

Learnt from: Lihlu
Repo: shesha-io/shesha-framework PR: 4132
File: shesha-reactjs/src/components/layerEditor/modal.tsx:55-57
Timestamp: 2025-11-05T07:46:22.081Z
Learning: In shesha-reactjs layer editor modal (src/components/layerEditor/modal.tsx), the useDeepCompareEffect that syncs items to the parent via onChange should only depend on [items], not [items, onChange]. Adding onChange to the dependency array causes the effect to fire on every parent render and breaks functionality. The guard for optional onChange is needed but the function reference should not be in the dependency array.

Applied to files:

• shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx

📚 Learning: 2025-07-19T10:27:44.987Z

Learnt from: teboho
Repo: shesha-io/shesha-framework PR: 0
File: :0-0
Timestamp: 2025-07-19T10:27:44.987Z
Learning: In shesha-reactjs code editor settings, removing the "availableConstantsExpression" property forces the code editor to expose the default list of exposed variables instead of a custom subset. This is useful when you want to provide access to the full range of available variables rather than maintaining a custom limited list.

Applied to files:

• shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx

🔇 Additional comments (5)

shesha-reactjs/src/components/settingsEditor/provider/models.ts (1)

17-17: LGTM! Property addition is consistent with existing pattern.

The new isUserSpecific boolean property follows the same pattern as the existing isClientSpecific property and is properly typed.

shesha-reactjs/src/components/settingsEditor/provider/index.tsx (3)

45-45: LGTM! Property correctly added to fetch query.

The isUserSpecific property is appropriately included in the GraphQL-like properties string to fetch from the backend.

---

67-67: LGTM! DTO interface correctly extended.

The isUserSpecific boolean property is properly added to the SettingConfigurationDto interface, consistent with the data model changes.

---

93-106: LGTM! Property mapping is correct and consistent.

The isUserSpecific property is properly mapped from the DTO to the ISettingConfiguration object at line 104, maintaining consistency with the existing mapping pattern for isClientSpecific.

shesha-reactjs/src/components/settingsEditor/settingsMenu.tsx (1)

83-85: Filtering logic correctly excludes user-specific settings from general settings list.

The updated condition appropriately prevents user-specific settings from appearing when no application is selected. The backend API explicitly returns the isUserSpecific property for all SettingConfiguration entities in the generic entity endpoint query, confirming this filtering logic operates on valid data returned from the backend.

---

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.}

[IvanIlyichev]

Hi @EthanJappie. Build of @shesha-io/reactjs fails because of console logging and usage of unknown isUserSpecific property

[EthanJappie]

Hi @EthanJappie. Build of @shesha-io/reactjs fails because of console logging and usage of unknown isUserSpecific property

Removed log and updated model