By changing the naming we make it clearer _why_ we want elements to be visible (because the loaded data is ready). Also `v-if` already implies the meaning of the original term (if the expression inside v-if resolves to true the content will be visible).
The new naming is borrowed from https://vueuse.org/core/useAsyncState/.
This loading is still missing error handling, but I want to separate that in another change
Nothing world changing. I realised recently that I prefer explicitly calling methods of stores and do the same with their states.
Similar to how one would do that with classes.
Since I might make more changes like this in the future (maybe also part of other PRs) I though I'd explain my reasoning here in a bit more detail:
__Benefits__
- saves local mappings, like the `const updateConfig = () => configStore.update()`
- there is no need to look up what exactly is updated, since the function is provide by the store.
__Disadvantages__
- a little bit more verbose (but not thaaat big difference)
---
TLDR: When reading the code this saves the step to check what was mapped.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2945
Reviewed-by: konrad <k@knt.li>
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
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>
This fixes a bug where the "import your tasks from other platforms" would be shown even if the user had already imported tasks. The bug was caused by the heuristic "there are tasks" was not evaluated when tasks were loaded through a filter
Resolves https://github.com/go-vikunja/vikunja/issues/372
This fixes a bug which caused fetching saved filter and favorite projects to crash, because the respective project ID is not a valid project id without special handling.
Because the "all projects" handler is the same as the one to fetch a single project, the handler would fail because no project was specified. However, it should return an empty project instead so that it later fetches all projects.
Resolves https://community.vikunja.io/t/http-400-when-trying-to-connect-via-caldav/3054
The healtcheck takes really long to initialize, which might cause unnecessary downtime. This removes the default healthcheck from the dockerfile to avoid that for all users. It is still possible to add the healthcheck manually.
Quote:
> Vite's default browser support baseline is Native ESM, native ESM dynamic import, and import.meta. This plugin provides support for legacy browsers that do not support those features when building for production.
Since all three feature now have more than 97% market share it seems fine to remove them.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2921
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
Because the tasks were emitted as the relation was created, when a task had multiple subtasks the parent was emitted multiple times and thus, shown multiple times in the list view. This change fixes that behaviour by emitting all tasks at the end, when all relations are created.
This fixes a bug where a saved filter would contain many "dead" entries for tasks which are not part of that filter. These entries were "dead" because the filter would not match for them and thus they were not shown.
The problem was caused by a routine during the creation of the filter where all projects from all matching tasks would be used as input for fetching the tasks to add to task_positions.
https://community.vikunja.io/t/not-able-to-move-task-between-buckets-within-a-kanban-view-for-saved-filter/2882/3
