[heinrich-toews]

• Resolves: Save filters #2861
• Target version: main

Summary

This adds per-user saved board filter views and an optional per-user default view.

Saved board views

• New BoardView entity, mapper, service and OCS API controller.
• CRUD routes under deck/api/v1.0/views (index/create/update/delete).
• The filter popover lets you save the active filter as a named view, re-apply it, and delete it.

Default view

• ConfigService::defaultBoardView persisted per user.
• New picker in Deck settings to choose the default view.
• When opening a board, the default view is applied automatically; tags are only applied where they match the current board.
• Note: this is a per-user default that applies to all boards, not a per-board default. If a per-board default is preferred, I can change it.

Migration

• Version11003Date20260821120000 creates oc_deck_board_views with indexes for (board_id, owner) and owner.

Hardening

• Names are trimmed and limited to 255 characters; filters are validated and size-limited.
• A maximum of 50 saved views per board.
• Deleting a view also clears it as the default view.
• Rebased onto current main and ported to the Pinia settings store; Vue.set is no longer used.

Testing

• composer test:unit — BoardViewServiceTest (12 tests) and the new ConfigService default-view tests pass.
• vendor/bin/psalm --no-cache — no errors.
• composer cs:check, npm run lint, npm run stylelint — clean.
• npm run test, npm run build — pass.
• Manually checked against a dev instance via the OCS API and a browser:
  • create, list, apply, update and delete a saved view;
  • set/remove the default view and confirm it is applied on board reload;
  • select the default view from the settings picker;
  • confirm a user without board access gets 403 and cannot see another user's views.

Note: l10n/* is intentionally not included per the project's Transifex workflow — translations are managed upstream.

[heinrich-toews]

Hi — this is a first contribution from a fork, so the GitHub Actions workflows are pending approval. Could a maintainer approve the workflow runs so CI can execute? Thanks!

[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.)

[heinrich-toews]

Hi @grnd-alt and @luka-nextcloud — friendly bump on this PR, which has been open since Aug 27.

I've rebased it onto current main (it was 300+ commits behind) and ported it to the new frontend architecture:

• resolved the conflicts in ConfigService.php, Controls.vue, DeckAppSettings.vue and BoardApi.js;
• migrated the settings integration from Vuex to useSettingsStore (Vuex and Vue.set were removed from main);
• hardened the API: name/filter validation, an owner index, a cap on saved views per board, and clearing the default view when its view is deleted;
• added unit tests for validation and default-view cleanup.

Local checks pass: composer cs:check, vendor/bin/psalm --no-cache, composer test:unit (BoardViewService 12/12 and the new ConfigService tests), npm run lint, npm run stylelint, npm run test, npm run build.

I also verified the flow end-to-end on a dev instance through the OCS API and a browser: create/apply/delete a saved view, set and remove the default view, pick the default in Deck settings, and confirm cross-user access returns 403.

Two asks:

1. Could a maintainer approve the workflow runs for the latest commit? This is my first contribution from a fork, so the lint/PHPUnit/Psalm jobs have never executed — only DCO has.
2. Is the scope right? The saved-views commit addresses the core of Save filters #2861. The second commit adds a per-user default view that is applied when opening any board (tags only where they match). I'm happy to split that into a follow-up, drop it, or change it to a per-board default. If you'd prefer shareable URL-parameter views first, tell me and I'll rework it.

Thanks!

[grnd-alt]

Hello there, thanks for contributing, and please excuse me not getting to it earlier.

I like the changes idea itself but see some issues.

• If we persist filters in the database I think we should not do it per user but per board for all users to see. I don't see any obvious drawback to that.

• The views are not deleted from the database as far as I saw. That will lead to the database entries growing and growing overtime as boards are deleted

• new endpoints should be OCS controllers only

• The filters are not really validated, it's only checked if the stored value is valid json not if it's anything sensible, wrong json will probably break the rendering (didn't test that though). That will get especially problematic when some of the filters change and are not reshaped in the json fields in the future

I see that last point is relatively hard to fix but I don't like storing json in the database tbh, especially since only the frontend verifies it, and at that without any recovery mechanism to fix the json. So it would be nice to have a better approach here. Two ways would be to verify the json on the backend side or store actual filter values in the db instead of a json text field. With actual filters stored we could also add methods for backend filtering instead of only ui filters in the future so I would prefer that.

As these are some fundamental structural issues I see I did not yet review specifics in detail

[grnd-alt]

@heinrich-toews I would prefer some more brainstorming here with you to get this feature done in a maintainable fashion, without you implementing things first and then having to redo it because of the reviews. I am open to different approaches as well here, what are your thoughts on the things I posted?