Deleting a calendar does not actually delete the calendar

[eesko]

In ownCloud 9.0.0/Calendar 1.0 deleting a calendar does not actually delete the calendar. The calendar is still reachable via dav. When creating a new calendar with the same name it is issued a new dav name where the calendar name is followed by "-1"

Steps to reproduce

1. Create a calendar
2. Delete the newly created calendar
3. Create a new calendar with same name as the deleted one

Expected behaviour

A single calendar exists that is reachable via dav at owncloudhost/remote.php/dav/calendars/user/calendarname and via the web interface where it is named calendarname

Actual behaviour

Two calendars exist that are reachable via dav:
owncloudhost/remote.php/dav/calendars/user/calendarname
and owncloudhost/remote.php/dav/calendars/user/calendarname-1
only calendarname-1 is reachable via web interface where it is named calendarname

Server configuration

Operating system: Linux 3.14.50

Web server: Apache 2.2

Database: MariaDB 10.0.23

PHP version: 5.4.45

ownCloud version: 9.0.0

Calendar version: 1.0

Updated from an older ownCloud or fresh install: fresh install

Signing status (ownCloud 9.0 and above): No errors have been found.

List of activated apps:
Enabled:

• activity: 2.2.1
• calendar: 1.0
• contacts: 1.0.0.0
• dav: 0.1.5
• federatedfilesharing: 0.1.0
• files: 1.4.4
• files_trashbin: 0.8.0
• files_videoplayer: 0.9.8
• gallery: 14.5.0
• updatenotification: 0.1.0
  Disabled:
• comments
• encryption
• external
• federation
• files_external
• files_pdfviewer
• files_sharing
• files_texteditor
• files_versions
• firstrunwizard
• notifications
• provisioning_api
• systemtags
• templateeditor
• user_external
• user_ldap

The content of config/config.php:
{
"system": {
"instanceid": "oc6ejbjoem34",
"passwordsalt": "_REMOVED SENSITIVE VALUE",
"secret": "_REMOVED SENSITIVE VALUE",
"trusted_domains": [
"removed"
],
"datadirectory": "/home/users/removed/owncloud_data",
"overwrite.cli.url": "https://removed/owncloud",
"dbtype": "mysql",
"version": "9.0.0.19",
"dbname": "removed",
"dbhost": "removed",
"dbtableprefix": "oc_",
"dbuser": "_REMOVED SENSITIVE VALUE",
"dbpassword": "_REMOVED SENSITIVE VALUE",
"logtimezone": "UTC",
"installed": true
}
}

Are you using external storage, if yes which one: local

Are you using encryption: no

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

Client configuration

Browser: Vivaldi 1.0.403.24 (Beta 3) (32-bit)

Operating system: Windows 7

CalDAV-clients: Lightning 4.0.6, Windows phone 8.1, davDroid 0.9.1.3

Logs

Web server error log

ownCloud log (data/owncloud.log)

Browser log

[georgehrke]

In ownCloud 9.0.0/Calendar 1.0 deleting a calendar does not actually delete the calendar.

Can't reproduce.
Does it work for you in Chrome or Firefox?

[georgehrke]

owncloudhost/remote.php/dav/calendars/user/calendarname
and owncloudhost/remote.php/dav/calendars/user/calendarname-1
only calendarname-1 is reachable via web interface where it is named calendar name

This doesn't make any sense.
The calendar app uses caldav to get information about available calendars and events, so if there would be a calendar called calendarname, the calendar app would show it.

Please make sure that this is no caching issue!

[eesko]

Fiddled around a bit more: Reloading the Calendar app by selecting it from the menu fixes the issue. But if I delete and create a calendar with the same name and do not refresh between the actions, the new calendar will have the wrong name. The issue happens for me in Firefox as well.

My use case is that I occasionally get a list of event as an ics file. I have a calendar for these events where I import the ics file. Sometimes a new file contains updates to several events that have been imported previously. In this case it is easiest to just delete the calendar, recreate a new calendar with the same name and import the new ics file.

If I do this now and don't reload the calendar between deleting and re-creating the calendar, the new calendar will have the wrong name for dav and calendars/devices that are connected to the proper calendar name will fail.

The calendar should get deleted when the delete button is pressed, not when the calendar app is reloaded.

[georgehrke]

I delete and create a calendar with the same name and do not refresh between the actions, the new calendar will have the wrong name.

That's the intended behavior at the moment.

[eesko]

The intended behavior is broken in my opinion.

[georgehrke]

We will need the current behavior when we implement #252.

[eesko]

At least the web interface should indicate that the name of the new calendar is not what the user typed but something else.

[georgehrke]

you can hover over the calendar name and wait for the tooltip to appear to see the entire caldav url

[eesko]

Maybe gray out the deleted calendar to indicate that the name is not free to use and signal an error to the user if they try to create a new calendar with the same name.

[eesko]

Oh. Thanks. Hadn't realized that there was a tool tip. Had to find out the new url by trial and error. Was only clued into the different name of the calendar when downloading the calendar and looking at the file name.

The tool tip doesn't really cover the functionality of the old "link to the dav url" button that no longer exists. I can't copy and paste a tool tip.

[eesko]

Anyway the point is that the calendar app in some cases silently renames the calendar to a different name than what the user intended but still displays the name that the user typed in. Having to check the tooltip is not really a sufficient solution.

[georgehrke]

We only have this tooltip because Thunderbird is not capable of discovering calendars on it's own.
Other caldav clients are perfectly able to do this :/

[eesko]

What I'm trying to do by recreating the calendar with the same name is to avoid having to do the discovery again for all clients and just have the calendar work.

[georgehrke]

Usually caldav clients should do this automatically and just show new calendars without the need for the user to interact 😉

That's a very special use case. Is there a way for you to automatically import the calendar? You could just delete all events previous to the import.

[eesko]

Hmm. Need to check. I haven't noticed either davDroid or Windows Phone doing this.

You are right on this being a special use case and that just deleting the events would be easier. In fact this is what I did with ownCloud 8. When importing a calendar there was a choise of clearing the calendar of all events before the import. This choise does not exist in ownCloud 9/Calendar 1.0. I can't find any way of clearing the calendar apart from manually removing all events one by one.

The number of events in the calendar is way too high to be doing this manually. This is why I resorted to deleting and recreating the calendar.

[eesko]

Perhaps this issue shoud be closed and a new one opened about the missing "clear calendar" option when importing a calendar.