fix(settings): reset limit to groups state when switching apps

[Pringels]

• Resolves: "Limit to groups" changes setting for all apps, not just the selected #20685

Summary

Fixes an issue where "Limit to groups" settings leak between apps when navigating the sidebar.

Before:

Nextcloud_server_20685_before.mp4

After:

Nextcloud_server_20685_after.mp4

Vue was recycling the AppDetailsTab component, preserving its local state. I added :key="app.id" to AppStoreSidebar to force component re-creation when switching apps.

Why this approach?
I opted to force a re-mount instead of manually resetting state. While this introduces a negligible performance cost compared to instance reuse, it guarantees a 100% clean state for every app and allows us to remove fragile watcher logic. This makes the code more robust and easier to maintain.

A note on testing
Unit tests were skipped because the settings app doesn't have a test harness set up yet.
I also looked into adding this to the existing Cypress E2E tests, but it felt like overkill to spin up a full browser session just to check a checkbox state reset.

I manually verified the fix by switching between apps and confirming the "Limit to groups" setting resets correctly every time.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[provokateurin]

/backport to stable32

[provokateurin]

/backport to stable31

[artonge]

Wouldn't a watcher on app work in this case? This would allow the AppDetailsTab component to properly react when the app changes.

[Pringels]

Wouldn't a watcher on app work in this case? This would allow the AppDetailsTab component to properly react when the app changes.

Yes, you're right that a watcher would work here, but I’d prefer to stick with the key approach.

The component relies on the AppManagement mixin which initializes state in mounted(), and also has its own local state like removeData and deployOptions that would need to be manually reset. Using key guarantees a clean state every time and feels much more future-proof, as we won't need to remember to update a watcher every time we add new local state or initialization logic.

[susnux]

Using key guarantees a clean state every time and feels much more future-proof

Well its a performance drawback, on the long run we should properly clean the internal state so that we can reuse the mounted component. But agree with that mixin its harder to keep track of state, an additional reason to finally remove all of them.

[Pringels]

Using key guarantees a clean state every time and feels much more future-proof

Well its a performance drawback, on the long run we should properly clean the internal state so that we can reuse the mounted component. But agree with that mixin its harder to keep track of state, an additional reason to finally remove all of them.

Agreed on all counts. The performance hit should be negligible for this component, but refactoring out the mixins to enable proper state reuse is definitely the better long-term goal

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)