When reproducing, it’s true that certain uniqueness constraints on fields cause problems.
Yes, sharing calendars internally in Gladys is a good solution.
Later, I would still like to fix this uniqueness issue because imagine a family using the same Nextcloud instance (or iCloud, Google… I don’t think it’s possible with Radicale) if they configure the shares directly in the Nextcloud calendar, the external IDs will probably be the same during synchronizations.
In any case, this requires development in both cases. The internal sharing in Gladys should not be a problem, but fixing the uniqueness will be a headache. For the selectors, I agree with you Pierre-Gilles. But there is also the external ID and we fall back on the same problems mentioned here Gladys V4 - Affichage de capteurs dans l'interface - #11 par pierre-gilles when we want to remove the constraints. For example, I would like to remove the uniqueness constraint on t_calendar.external_id which in itself is not necessary between several users because when we retrieve a calendar we specify its user. At most, if we really want one, we can put it on the whole external_id + user_id.