- Navios
- 10 de agosto de 2026 às 14:13 UTC
- Autor
- Kamo
- Enviar
- 4bd974a
EmailService agora examina todos os contatos lidos para contact books.owner id, que deixa os contatos já sentados em uma organização-padrão sem proprietário livro inatingível. CONTACT.OWNER ID NÃO é NULL e foi povoado em cada linha desde que o caminho de criação começou a defini-lo, então o membro que adicionou cada contato é conhecido exatamente — nada é inferido. Esta disposição livro pessoal por (organização, proprietário) e move cada contato para o seu Do próprio proprietário. Duas coisas estão deliberadamente encalhadas e contadas no diário de bordo em vez de forçado: - Colisões de UID. uk contact uid book é único em (UID, CONTACT BOOK ID), então um contato cujo UID já existe no destino falharia Toda a atualização e nada. Essas linhas ficam paradas; reescrever um UID seria Quebre o cliente do CardDAV que o emitiu. - Grupos de propriedade mista. Uma linha contact groups tem um livro mas nenhum proprietário, então um grupo cujos membros pertençam a várias pessoas não pode ser atribuído a Um deles. Apenas grupos cujos membros compartilham um único proprietário são movidos. O próprio livro sem dono é mantido: sua restrição de cheque é o que o torna legal, e derrubá-lo seria cascata em grupos e membros. O controle de conta encalhada testa contatos e grupos, não apenas contatos. A grupo é atribuído através dos proprietários de seus membros em vez de através de onde esses membros vivem, assim os grupos permanecem móveis depois de cada contato já moveu- se; contando os contatos sozinho os ignoraria em uma segunda execução.