This fixes a bug where the task delete modal was not visible on mobile when the task itself was opened in a modal (for example, when opened via the kanban board). This was caused by both the delete modal and the task modal being teleported outside of the app.
Partially resolves https://github.com/go-vikunja/vikunja/issues/383
This partially reverts a change introduced in ca1384e3c9 which led to a bug where a comment on a task, which was just saved, stayed in the editor. The editor switched to read-only mode after that.
I'm still unsure if we should keep this rule in general, in this specific case I think it makes sense to reverse the logic and enable this api config explicitly
This improves (!) the types of Multiselect — it doesn't fix them
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2618
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
There might be future general improvements like merging the edit and info modal (since they both show the description, but only in one it's editable.
This PR already improves the situation a bit, since you don't have to click on that info button anymore to check __if__ there is a description at all.
This will not fix the current issues yet, but I think it makes sense to start with this to rule this out.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2453
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>
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>
kolaente
Dominik Pschenitschni
Harry Martland