a workaround could be to create a trash calendar first. Afterwards you can use this script or some sql to archive the entries before day X. And finaly delete the trash calendar.

Regards Martin

Am 06.02.2018 um 22:53 schrieb Till Dörges: > Hello all, > > I'm looking for an automated way to delete entries older than X days from a calendar. > > > I found scripts/archive-old-events.php which seems to be quite close, but I don't > want the archive part. > > From quickly skimming through the code, simply removing any reference to > $archive_collection_sql doesn't appear to do the trick. > > > What's the best way to go about this? > > > Any hints/pointers would greatly be appreciated. > > > Thanks and regards -- Till

I just checked my sql-script that is used for archiving events. I think it will do to delete calendar_item and caldav_data entries. Besides you should pay a little attention to repeating events.

Regards Martin

Am 07.02.2018 um 20:17 schrieb Till Dörges: > Am 07.02.2018 um 19:56 schrieb Martin Stöcker: > >> a workaround could be to create a trash calendar first. >> Afterwards you can use this script or some sql to archive the entries before day X. >> And finaly delete the trash calendar. > I actually need a cron job (or something similar) to make sure that my calendar does > not contain any events older than X days. > > So If I understand correctly I would have to > > 1) create a trash/archive collection > 2) run scripts/archive-old-events.php on my calendar moving > stuff to the trash/archive collection > 3) delete the trash/archive collection > > I guess then I'll also have a look at scripts/davical-cli, which might help me with > 1) and 3). > > Thanks and regards -- Till

>> So If I understand correctly I would have to >> >> 1) create a trash/archive collection >> 2) run scripts/archive-old-events.php on my calendar moving >> stuff to the trash/archive collection >> 3) delete the trash/archive collection 1) does not seem to be required. At least archive-old-events.php creates a new archive collection, if it doesn't exist already.

But an event that I created in foo/bar/ on Jan 2, 2018 is still there when looking at my client. It is not deleted. However, something does seem to happen, because if I try to modify the test event using my client, I get a complaint that the event has already been modified on the server.

I'm a bit uncertain how to proceed. Any pointers would be welcome.

Am 08.02.2018 um 08:37 schrieb MS (direkt):

> I just checked my sql-script that is used for archiving events. > I think it will do to delete calendar_item and caldav_data entries. > Besides you should pay a little attention to repeating events.

Could you perhaps share your script?

>> I guess then I'll also have a look at scripts/davical-cli, which might help me with

FTR, scripts/davical-cli doesn't work on my openSUSE Leap 42.3 system. It looks like the script has problems when parsing the output from 'ps'. Haven't looked into it any further.

Also my DAViCal client (Thunderbird) keeps complaining that the events which were archived (more like copied in my case) were modified on the server. But they are still shown in /foo/bar/ by Thunderbird.

Is that perhaps because the column 'dav_name' exists in both the tables caldav_data and calendar_item, but is only updated in the former by the above statement?

I also experimented a bit with statements along the lines of

DELETE FROM caldav_data WHERE collection_id = :source_collection_id AND dav_id IN ( SELECT dav_id FROM calendar_item WHERE ( (rrule IS NULL AND dtend < :archive_before_date) OR (last_instance_end < :archive_before_date) ) );

But couldn't get it working.

So I guess, I'm still looking for a way to either archive or delete events from a calendar which are older than a certain number of days.

I would suggest to try and take Thunderbird out of the equation, because it keeps its own calendar store and you want to be able to differentiate between "event isn't moved properly on the server" and "changed event isn't synced properly to TB". Enable GET on collections (or use curl to send a caldav REPORT request) to see if the server still includes the event in the non-archive collection. I could imagine the scripts failing to generate a new sync token, and hence TB failing to find out about the change until it tries to modify a changed event.

> Is that perhaps because the column 'dav_name' exists in both the tables caldav_data > and calendar_item, but is only updated in the former by the above statement?

I would expect this to be taken care of by a function/trigger in the database.