Differences

This shows you the differences between two versions of the page.

--- doc:appunti:calendar_contacts_private [2019/11/28 12:06] – [Creazione di un calendario di gruppo] niccolo
+++ doc:appunti:calendar_contacts_private [2021/08/27 15:47] (current) – [Problema di sincronizzazione] niccolo
@@ Line 95: / Line 95: @@
 Il sistema Android usa **tecniche aggressive per il risparmi di batteria**, questo affligge soprattutto le app non di sistema tipo DAVdroid. In pratica accade che **viene inibita la sincronizzazione** con il server: quando l'app è in background non viene mai svegliata.
-Avviando l'app DAVdroid si viene avvisati di questo potenziale problema da tre pop-up:
+Avviando l'app DAVx5 si viene avvisati di questo potenziale problema da tre pop-up:
   * Battery ... ?
@@ Line 198: / Line 198: @@
 === Creazione di un Principal di tipo Group ===
+Il //principal// di tipo //group// avrà il suo login e la sua password, ma le credenziali non verranno condivise con gli utenti che avranno accesso al calendario. Il calendario (in effetti una //collection//) sarà creato come appartenente a questo gruppo.
   * User Functions => Create Principal
@@ Line 206: / Line 208: @@
     * Principal Type: Group
-=== Creazione di una Calendar Collection nel Group ===
+=== Aggiunta degli User al Group ===
+FIXME Serve davvero? Oppure è sufficiente creare il Ticket (vedi avanti)?
+  * User Functions => List Groups => (click su ID)
+    * Group Members => (select the user) => Add
+    * Group Members => (select the user) => Add
+=== Creazione di un Calendar Collection nel Group ===
   * User Functions => List Groups => (click su ID)
@@ Line 218: / Line 228: @@
         * (select the user): ALL (FIXME Serve davvero? O basta il ticket?)
         * (select the user): ALL (FIXME Serve davvero? O basta il ticket?)
+L'URL completo del calendario è **%%https://dav.domain.tld/dav/caldav.php/caldavtest@domain.tld/calendar/%%**, ma non si userà questo per l'accesso. La risorsa verrà ricollocata (**bind**) come risorsa di ciascun utente.
 === Creazione di un Access Ticket per la Collection ===
@@ Line 227: / Line 239: @@
       * Expires: 2029-12-29
       * Privileges: ALL
-      * Create
+=== Binding della Calendar Collection allo User ===
+Con questa operazione, il calendario condiviso (che ha URL **%%/caldavtest@domain.tld/calendar/%%**) verrà mappato come risorsa dell'utente (con URL **%%/user1@domain.tld/boundcalendar/%%**):
+  * User Functions => List Users => (click su ID)
+    * Bindings to other collections
+      * ID Bounds As: /user1@domain.tld/boundcalendar/
+      * Display Name: Calendario condiviso
+      * To Collection: /caldavtest@domain.tld/calendar/
+      * Ticket ID: Nfe5wq0Y
+L'URL completo del calendario diventa quindi **%%https://dav.domain.tld/dav/caldav.php/user1@domain.tld/boundcalendar/%%**. In generale non si dovrà indicare l'URL per esteso, perché il client (es DAVx5 su Android) elencherà il nuovo calendario nell'elenco di quelli disponibili, con l'etichetta impostata in //Displayname//.
+===== Aggiornamento del database di backend =====
+Dopo l'aggiornamento da Debian 9 Stretch a **Debian 10 Buster**, quando ci si collega all'interfaccia web di Davical (nella nostra installazione è qualcosa del tipo **%%https://dav.host.tld/dav/%%**), si legge il seguente warning:
+<code>
+Database schema needs upgrading. Current: 1.3.2, Desired: 1.3.3
+</code>
+Si è deciso di agire da riga di comando. Anzitutto si crea un file **/etc/davical/administration.yml** con le credenziali per accedere al database (proteggere il file con **mode 600**):
+<file>
+admin_db_user: davical_dba
+admin_db_pass: MySecret
+admin_db_host: 127.0.0.1
+</file>
+Quindi si esegue lo script **/usr/share/davical/dba/update-davical-database** che provvede ad applicare tutte le patch incrementali allo schema del database. Ovviamente si consiglia di fare un backup del database **prima** di eseguire la procedura.