This fixes two closely-related bugs:
1. When loading tasks from a bucket of a saved filter, the saved filter query would override the user-supplied filter, which would cause to only tasks matching the saved filter query to be returned.
2. When a filter query for a bucket was specified, the function would only check if one of the top level filters was a filter for tasks in a specific bucket. That means a filter like "bucket_id = 42 && labels = foo" would return the expected result, while a filter like "labels = foo && (bucket_id = 42 && priority = 1)" would fail with an error 500 because the task_buckets table was not joined to the sql query. The fix from the first bug caused such filter queries.

With this change, it is possible to cancel editing the task title with pressing the escape key.

# Problem

Before it was not possible to cancel editing the task title. Pressing outside the title saves the changes that have already been done (which is intended I think). But when e.g. pasting something with a wrong format, I was not able to revert the change without saving and editing it again

Example: after accidentially pasting something with multiple lines it is not possible to escape, the only way to revert this is to save and edit again manually:
![grafik.png](/attachments/11d3559a-3111-458f-9a9c-4107292054fa)

# Solution

This PR implements a listener for the escape key that sets the title back to its original value and blurs the focus of the title

# Additional notes

- I checked this in the "page" view of the task and the "popup" view and it worked in both. For me, the popup does not close with the escape key (as it often does on other sites), therefore there is no collision with this function. But I think it would be good to check this again to make sure it does not break anything like this
- I don't know anything about testing in this repository, if it is possible/necessary to implement a test for this feature please leave a comment :)

Co-authored-by: Daniel Pantle <daniel.pantle@newtec.de>
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2730


Co-authored-by: DanielPantle <danielpantle@noreply.kolaente.dev>
Co-committed-by: DanielPantle <danielpantle@noreply.kolaente.dev>

Resolves https://vikunja.sentry.io/share/issue/6f1e37d4b8b248188e20650234a45cde/

Mysql cannot handle year values < 1. That means filtering for a date value like 0000-01-01 won't work with mysql. Additionally, dates like 0001-01-01 could under some circumstances not work either when the date in combination with the time zone would resolve to something like 0000-12-31 - for example when the server is located (and configured) in UTC, but the user running the query is in New York. This could be observed by setting the time zone manually using the filter_timezone query parameter.

Resolves https://vikunja.sentry.io/share/issue/42bce92c15354c109eb1e6488b6a542b/
Resolves https://vikunja.sentry.io/share/issue/ef81451b0c7b43f1bff2d3a86ba393bb/

Trying to debug https://vikunja.sentry.io/share/issue/ef81451b0c7b43f1bff2d3a86ba393bb/

Trying to debug https://vikunja.sentry.io/share/issue/ef81451b0c7b43f1bff2d3a86ba393bb/

This fixes a regression introduced in daa7ad05 where the root path would be included twice in the file path, leading to retrieval issues.

Resolves https://vikunja.sentry.io/share/issue/ef81451b0c7b43f1bff2d3a86ba393bb/
Resolves https://github.com/go-vikunja/app/issues/94#issuecomment-2351818484

This commit introduces the automatic retrieval of TLS certificates from Let's Encrypt. If the feature is enabled, Vikunja will automagically request a certificate from Let's Encrypt and configure it to server content via TLS.

Resolves https://github.com/go-vikunja/vikunja/issues/329

Resolves https://github.com/go-vikunja/vikunja/issues/330
Resolves https://community.vikunja.io/t/add-task-to-filter-view-cron-error-fetching-filters-pq-operator-does-not-exist-json-unknown/2831