Calendar unexpectedly gets deleted when deleting a task list

[p4t5h3]

I decided to stop using the tasks app. Today I cleaned up and deleted all tasks lists. A few hours later I was surprised to see my personal calendar with all of my appointments and so on being gone without a trace. Luckily I have at least daily backups…

Steps to reproduce

1. Delete all task lists.
2. Open the calendar app.
3. See your personal calendar app gone.

Expected behaviour

My personal calendar with scheduled items (not tasks) should be still there.

From user experience there should be a clear separation between calendars and task lists. It is easy to fuck up all calendars while thinking you are just cleaning up your task lists. In example at least one task list must be obligatory.

Actual behaviour

My personal calendar which I used for everything simply was not there anymore.

Server configuration

(Official Nextcloud Snap)

Operating system: Ubuntu Server 18.04 LTS

Web server: Apache

Database: mysql

PHP version: 7.1.22

Nextcloud version: 13.0.7

Tasks version: 0.9.7

Updated from an older Nextcloud or fresh install:

Signing status:

No errors have been found.

List of activated apps:

Enabled:
  - activity: 2.6.1
  - calendar: 1.6.1
  - comments: 1.3.0
  - dav: 1.4.7
  - federatedfilesharing: 1.3.1
  - federation: 1.3.0
  - files: 1.8.0
  - files_sharing: 1.5.0
  - files_texteditor: 2.5.1
  - files_trashbin: 1.3.0
  - files_versions: 1.6.0
  - files_videoplayer: 1.2.0
  - firstrunwizard: 2.2.1
  - gallery: 18.0.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.1.0
  - nextcloud_announcements: 1.2.0
  - notifications: 2.1.2
  - oauth2: 1.1.1
  - password_policy: 1.3.0
  - provisioning_api: 1.3.0
  - serverinfo: 1.3.0
  - sharebymail: 1.3.0
  - survey_client: 1.1.0
  - systemtags: 1.3.0
  - theming: 1.4.5
  - twofactor_backupcodes: 1.2.3
  - workflowengine: 1.3.0
Disabled:
  - admin_audit
  - contacts
  - encryption
  - files_external
  - files_pdfviewer
  - news
  - notes
  - tasks
  - user_external
  - user_ldap

Nextcloud configuration:

{
    "system": {
        "apps_paths": [
            {
                "path": "\/snap\/nextcloud\/current\/htdocs\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/snap\/nextcloud\/current\/nextcloud\/extra-apps",
                "url": "\/extra-apps",
                "writable": true
            }
        ],
        "supportedDatabases": [
            "mysql"
        ],
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0
        },
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***",
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "http:\/\/188.68.42.184",
        "dbtype": "mysql",
        "version": "13.0.7.2",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "maintenance": false,
        "loglevel": 2
    }
}

Are you using external storage, if yes which one: No.

Are you using encryption: No.

Are you using an external user-backend, if yes which one: No.

Client configuration

Browser: Safari 12.0

Operating system: MacOS Mojave

CalDAV-clients: Calendar app in iOS and macOS

[raimund-schluessler]

RFC4791 allows to store different types of calendar components (e.g. events or tasks) in a calendar object resource (referred to as "calendars" in the Calendar app or "task lists" in the Task app). The Task app shows all calendar object resources which allow to store tasks. Hence, it also shows "calendars" if they can be "task lists". Deleting a "task list" deletes the calendar object resource, which might store events as well.

The same thing will happen to you with every other CalDAV client. When you delete a "task list" in Thunderbird/Lightning, on your iOS device or on Android etc. you have to be aware that there might be calendar events stored in this list as well.

In order to make that more clear, we have recently adjusted the message that is shown when you delete a task list: https://github.com/nextcloud/tasks/issues/196. But there cannot be a change in the overall behavior. Because if we forbid to delete a list that could store events in the Task app, we would need to forbid to delete a calendar that could store tasks in the Calendar app. How would you then delete it at all?

In the future, lists that will be created in the Tasks app will be tasks only, preventing you from storing events. But this will also not prevent you from creating a calendar/list with another client that could store both. Overall, there will be no absolutely safe solution for this problem as a clear separation between calendars and tasks is not intended in the RFC standard. In the long run, a trash bin will help a bit, but if you delete the trash bin before recognizing your mistake, you will be screwed as well.

Also @jancborchardt and @georgehrke for other opinions/ideas.

[p4t5h3]

Ok. I probably should have actually read that message. After deleting some task lists I did not think about it anymore when it was really about calendars.

[raimund-schluessler]

Ok. I probably should have actually read that message. After deleting some task lists I did not think about it anymore when it was really about calendars.

That's the problem with warning messages, sadly. And also the reason why we want to implement a trash bin. But good that you had a backup. 👍

[jancborchardt]

Yeah, so a warning is not proper here. I would actually even say that:

• If you try to delete a task list which has a calendar attached which has events, you will see a warning telling you it won’t be possible until you clear the calendar
• And vice versa: If you want to delete a calendar which has a task list attached which has tasks, you will get a warning etc.

What do you think @georgehrke @raimund-schluessler? Yes I know it’s a bit more invasive, but preventing data loss is the most important thing we need to ensure. And it shouldn’t be mandatory for people to go around restoring backups.

[raimund-schluessler]

We would need a function to delete all events or tasks in a calendar in Calendar and Tasks respectively then. This can be done for sure.

But there a a number of problems/questions:

• How do you deal with VJournal entries in a calendar? As far as I know, there is no app which deals with this type of entries for Nextcloud, but hey could be created with other clients. Would you forbid to delete calendars with VJournal entries completely then?
• You can't prevent a user from deleting a calendar with events and tasks using other CalDAV clients. E.g. Thunderbird or iOS won't stop you from deleting such a calendar, they will just show a warning, that you delete events and tasks.

I think, a trashbin for calendars included in the server is the way to go. You could then restore a calendar with Calendar or Tasks if needed.

[jancborchardt]

We would need a function to delete all events or tasks in a calendar in Calendar and Tasks respectively then.

I’d even say this is a second step. First is the warning and blocking deletion. Sure, it necessitates that you manually delete the elements, but it’s better than losing them all.

"Trashbin" is this thought which has been thrown around a lot over the years, but the issue is that it’s very big overhead for quite little gain. Or at least that’s what it seems like, judging by that no one really stepped up to do it (which is fine). :)

[bcutter]

I´d love to see an option of hiding already existing calendars (with calendar objects/events, before starting using NC tasks). Will digg through all open issues/feature requests, if not existing already I´ll create one.

[georgehrke]

@bcutter The problem here is that the calendar-standard forces you to pick the allowed components (events, journals, todos) on creation of a calendar. It's explicitly forbidden to change the supported types afterwards.

[bcutter]

Well, there´s already a feature request for this - and it´s almost 3 years old shocked :-(

https://github.com/nextcloud/tasks/issues/84#issuecomment-317193302

[bcutter]

@bcutter The problem here is that the calendar-standard forces you to pick the allowed components (events, journals, todos) on creation of a calendar. It's explicitly forbidden to change the supported types afterwards.

I don´t care about the default calendars being able to support tasks. I want the webinterface to visibly hide them. Or integrate a folder hierarchy and move them to a subfolder. I - as many users I guess - only use my very specific lists (newly created "calendards") for tasks and really don´t touch my blown-up default calendards.

Even there´s the technical limitation according to the RFC, we should be able to work around that with some smart GUI tweaks. I mentioned two of such ideas. Third one (the one I prefer, cause it´s also a quick one): implement an option/selection list (configuration in the settings bar on the bottom left) "show all calendars / show only task calendars / show only event calendars". Bam.

[apiraino]

I can only upvote this issue because today I have unexpectedly deleted a calendar from the Tasks NextCloud App.

I find this feature extremely dangerous, this popup warning the user is imo not enough.

Please reconsider disabling this feature or at least putting it under a more prominent blocking popup thing!

As a user I find counter-intuitive that from Tasks I can delete something completely unrelated such as a Calendar.

I must uninstall this app now because I don't trust myself to not fall into this mistake again.

[raimund-schluessler]

I must uninstall this app now because I don't trust myself to not fall into this mistake again.

Again, this is the standard behavior of every CalDAV client, so you better uninstall them too. Thunderbird, Fantastical and the iOS standard apps will all delete a calendar when you ask them too, no matter if they contain events or tasks. And I am against disabling a feature, just because you can misuse it when ignoring the warnings. And judging from the upvotes on the 1.5 years old issue, it is not a highly required change.

But I am open to require a confirmation in a modal. However, I don't think it will help much, given that users apparently just ignore the warning messages that are already there. Also I am not aware of any other app or place in Nextcloud that uses a modal for confirmation. And if we decide to change it here, we also have to change it in the Calendar app, because you can also delete task lists from the Calendar app @georgehrke @nextcloud/designers.

[apiraino]

Hallo @raimund-schluessler thanks for the feedback :-) My apologies if I sounded aggressive.

I understand I maybe the wrong kind of user here, that's perfectly fine :-) and maybe not many upvotes but I see a little discussion in the past that didn't seem to land to an agreement. Understand also that resources are limited (especially when doing unpaid open-source!) so I don't want to create too much brainstroming on a non-issue.

Perhaps closing this issue as "WONTFIX" so no more complaints? Just an idea.

Anyway, thanks for working on Tasks :+1: :)

[raimund-schluessler]

Hallo @raimund-schluessler thanks for the feedback :-) My apologies if I sounded aggressive.

Don't worry, we probably all do sometimes when something is creating trouble, me included.

I understand I maybe the wrong kind of user here, that's perfectly fine :-)

There is no wrong kind of users, we try to make it work for everybody. I just find it very difficult to prevent users from doing something unwanted without limiting others that might want to do exactly this.

Perhaps closing this issue as "WONTFIX" so no more complaints? Just an idea.

It is not decided, that this is a won't fix issue. The approach with the modal could be a solution / improvement, I just want it to be a Nextcloud wide (or at least CalDAV-app-wide) solution.

[jancborchardt]

In this case where a lot of data can get lost, we really need to do better on error prevention. A tooltip does not suffice. We need a modal clearly stating:

Delete <name of calendar/task list> Deleting a task list will also delete the associated calendar. Please confirm the name of the task list to proceed: [ Task list name … ] ( Cancel ) ( Delete task list and calendar )

We should do it the same (just worded vice versa) in the Calendar app cc @georgehrke. This is also how e.g. GitHub handles repository deletion.

Also I am not aware of any other app or place in Nextcloud that uses a modal for confirmation.

We do in the admin settings for example on user deletion or modification where you have to type your password. Accidentally deleting your whole Calendar when you did not intend to is a case requiring similar means.

[tcitworld]

Is it worth it to have this kind of solution implemented until we have a Trashbin for calendars/tasks and it's not relevant anymore? Also it's kinda hard to determine whether the calendar holds a lot of data or not.

[raimund-schluessler]

I don't see the trash-bin happening anytime soon. And as far as I know, it would require server changes. So I am fine with the modal approach, which shouldn't be that much effort.

Also it's kinda hard to determine whether the calendar holds a lot of data or not.

I think @jancborchardt meant it should always be shown, no matter how much data a calendar holds. So no need to figure that out.

If we have the modal, should we still show the undo action then?

[jancborchardt]

• Yes, this should still happen even with trashbin. Also agree with @raimund-schluessler that trashbin will probably not happen anytime soon, so definitely not a blocker.
• Yes, it should always be shown, no matter how much data a calendar holds. This is to make clear that there is a connection between Calendar and Tasks.
• Yes, even with the modal there should still be undo. We always need to aid error prevention as best as we can. :)

---

That, or we actually somehow find a way that a task list can be deleted independently from an associated calendar – but I assume that’s more complicated still.

[georgehrke]

@raimund-schluessler Should we have a nc/vue component for this? We already have two apps which require it (Calendar / Tasks) and it might be useful for other apps too.

[raimund-schluessler]

@raimund-schluessler Should we have a nc/vue component for this? We already have two apps which require it (Calendar / Tasks) and it might be useful for other apps too.

I think that makes sense. It could be useful for Contacts or Deck as well, in case one deletes an adressbook or stack.

That, or we actually somehow find a way that a task list can be deleted independently from an associated calendar – but I assume that’s more complicated still.

As far as I know, the CalDAV specification still forbids to do that.

[georgehrke]

That, or we actually somehow find a way that a task list can be deleted independently from an associated calendar – but I assume that’s more complicated still.

As far as I know, the CalDAV specification still forbids to do that.

Correct. The CalDAV RFC forbids changing the support component set (whether a calendar can store events, tasks and or journals) after creation. Modifying that value anyway will probably break syncing for some clients.