Ça continue pour les actions.
La suppression est effective et un lien de suppression est créé. La suppression de l’objet proprement dit qui tient compte de la présence de liens d’autres entités. C’est la réponse à la réflexion sur le blog de nebule sur la multi-entité et la suppression d’objet. On verra dans le temps si cette façon de faire est correcte.
La restauration d’un objet précédemment supprimé est fonctionnelle. L’objet est synchronisé si disponible ailleurs. Le lien de suppression est annulé.
Une nouvelle action permet de définir un objet comme étant à bannir. Cela ne le supprime pas, mais cela empêche sa synchronisation si supprimé. Son affichage est restreint en conséquence dans les mode aff
, nav
et lnk
. Lorsque banni, un lien permet d’annuler le bannissement si nécessaire. Le bannissement tient compte des liens générés par les entités puppetmaster et cerberus.
Une nouvelle action permet à l’entité propriétaire du serveur de forcer la suppression d’un objet. Là , la suppression de l’objet est effective. Cette suppression n’est possible que si l’entité en cours est l’entité propriétaire du serveur, si l’entité est connectée, si l’objet est marqué supprimé par un lien, et si l’objet est encore présent.
Les variables $sylabe_permitsynclink
et $sylabe_permitsyncobject
sont maintenant sous la coupe de nebule en tant que $nebule_permitsynclink
et $nebule_permitsyncobject
. Elles sont utilisées directement en vérification dans les fonctions _l_dl1
et _o_dl1
. Les anciennes variables ne sont plus utilisées.
Le menu de gauche sur les nœuds a été corrigé dans sa forme et sa cohérence.