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
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 an issue where the default date for a new reminder was
1970-01-01 (unix timestamp 0). It was caused by a new date object being
created but since the reminder that was creatd was new, this was created
as null date, which equals a 0 unix timestamp.
Resolves https://github.com/go-vikunja/vikunja/issues/359
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2866
Reviewed-by: konrad <k@knt.li>
Co-authored-by: Harry Martland <HarryEMartland@gmail.com>
Co-committed-by: Harry Martland <HarryEMartland@gmail.com>
This should make it clear when a filter does not bring the expected results - maybe because it contradicts with the one set in the view.
Related to https://github.com/go-vikunja/vikunja/issues/296
Frederick [Bot]
Dominik Pschenitschni
kolaente
Harry Martland