Replaces 33 for...in loops across 18 files with for...of + Object.keys/entries
or indexed for loops. for...in iterates enumerable string keys including
inherited ones, which is especially risky on reactive arrays (tasks, labels,
assignees, etc.) where polyfilled properties may appear.
Loops that mutate via splice during iteration now iterate backwards to avoid
index-shift bugs. Adds a no-restricted-syntax ESLint rule forbidding
ForInStatement to prevent regressions.
Closes#513
Wraps all tables that were missing overflow handling in a
`has-horizontal-overflow` div to prevent horizontal overflow on mobile
viewports.
Affected components:
- Sessions.vue
- ApiTokens.vue
- ProjectSettingsWebhooks.vue
- LinkSharing.vue
- UserTeam.vue
- EditTeam.vue
- ProjectSettingsViews.vue
Fixes https://github.com/go-vikunja/vikunja/issues/2331
The is-danger class no longer worked on XButton because the component uses scoped CSS. This adds a proper danger boolean prop that applies danger styling (red background) as a color modifier that works alongside any variant (primary, secondary, tertiary).
The link share creation form is now hidden by default and only shown when users explicitly click the "Create" button. This reduces confusion in the sharing dialogue where users might mistake link sharing for team sharing.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: kolaente <13721712+kolaente@users.noreply.github.com>
This fixes a race condition and should potential fix some flaky Cypress tests:
<img width="630" alt="Screenshot 2024-12-12 at 10.53.56.png" src="attachments/21dce132-7f1a-4e19-b14c-b0a868daa20e">
-----
Before `selectedView` was filled with an initial value that depended on the the related project being loaded before the shared links, since the assignment happened directly after the views have been loaded.
This fix ensures that the correct project has been loaded before it's accessed to look up the id of the first view.
-----
@konrad: Now that I finished this PR I'm a bit unsure if it's the "correct" way to solve this.
Because for existing share links it might be better if the links save the selected view as a property. Currently a change of the view only changes the created link in the frontend. When you change the view and reload the link stays the same.
I'm unsure if editing the selected view is something that we want (or is even possible depending on what the hash represents).
So maybe we should only support the following: The user selects a view when creating a linkShare and and different from before it will be saved.
Even with those additional changes we still need something similar to the changes of this PR, since we would still need to load the available view ids for the creation of a new link share.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2932
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
Also added `Destructuring the 'props' will cause the value to lose reactivity` as a warning to prepare for the removal of the propsDestructure option in vite.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2396
Reviewed-by: konrad <k@knt.li>
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
kolaente
Copilot
Dominik Pschenitschni
Dominik Pschenitschni
waza-ari