Collaboration inactivity cronjob must check and respect `expiry_date` of CO #2058

New issue

Closed

opened 2025-09-10 11:15:36 +00:00 by logan-life · 2 comments

logan-life commented

2025-09-10 11:15:36 +00:00

(Migrated from github.com)

Collaboration inactivity / expiry cronjob does not check for the expiry_date of a given CO before taking action.

The expiry_date must be leading for this check, as the responsible organisation is the Data Controller and therefore must have the right to determine the data retention period.

Update the CO inactivity cronjob to check and respect the expiry_date of the CO.

Collaboration inactivity / expiry cronjob does not check for the `expiry_date` of a given CO before taking action. The `expiry_date` must be leading for this check, as the responsible organisation is the Data Controller and therefore must have the right to determine the data retention period. Update the CO inactivity cronjob to check and respect the `expiry_date` of the CO.

mrvanes commented

2025-10-09 14:02:48 +00:00

(Migrated from github.com)

MariaDB [sbs]> select id, last_activity_date, expiry_date from collaborations where id=11;
+----+---------------------+---------------------+
| id | last_activity_date  | expiry_date         |
+----+---------------------+---------------------+
| 11 | 2000-01-01 00:00:00 | 2000-01-01 00:00:00 |
+----+---------------------+---------------------+
1 row in set (0.000 sec)

Am I missing something?

I can exempt a CO from being suspended/deleted on inactivity by setting expiry_date in the future, but the following CO is not suspended while having both last_activity_date and expiry_date far in the past? ``` MariaDB [sbs]> select id, last_activity_date, expiry_date from collaborations where id=11; +----+---------------------+---------------------+ | id | last_activity_date | expiry_date | +----+---------------------+---------------------+ | 11 | 2000-01-01 00:00:00 | 2000-01-01 00:00:00 | +----+---------------------+---------------------+ 1 row in set (0.000 sec) ``` Am I missing something?

mrvanes commented

2025-10-10 07:28:59 +00:00

(Migrated from github.com)

There is a different cron job to expire co's with expiry_date. All good.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

eric/SBS#2058

No description provided.

Rows
Columns

Collaboration inactivity cronjob must check and respect expiry_date of CO #2058

Collaboration inactivity cronjob must check and respect `expiry_date` of CO #2058