Project

General

Profile

Development #69902

django_rbac, rapatrier le modèle Operation

Added by Valentin Deniaud 4 months ago. Updated about 1 month ago.

Status:
Solution déployée
Priority:
Normal
Category:
-
Target version:
-
Start date:
05 October 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Suite de #58696, avec pour objectif de vider l'app django_rbac.

Dans le précédent ticket on a simplement déplacé du code de modèles abstraits dans les vrais modèles, ce qui ne générait pas de migration de données. Ici il va falloir jouer une migration qui déplace le modèle d'une app à l'autre.


Files


Related issues

Related to Hobo - Development #70180: Changement d'import django_rbac -> a2_rbacFermé12 October 2022

Actions
Related to Authentic 2 - Development #70152: Lors de la génération des permissions d'un utilisateur, prendre en compte l'héritage entre modèlesFermé12 October 2022

Actions

Associated revisions

Revision 3dab8ff2 (diff)
Added by Valentin Deniaud 3 months ago

a2_rbac: move signal handlers from django_rbac (#69902)

Revision cb9df4fb (diff)
Added by Valentin Deniaud 3 months ago

a2_rbac: migrate existing operations to new model (#69902)

History

#1

Updated by Benjamin Dauvergne 4 months ago

PermissionMixin est abstract aussi tu peux le faire à part.

#2

Updated by Valentin Deniaud 4 months ago

Benjamin Dauvergne a écrit :

PermissionMixin est abstract aussi tu peux le faire à part.

Ah oui merci, j'avais raté ça.

#3

Updated by Valentin Deniaud 4 months ago

  • Subject changed from django_rbac, rapatrier les modèles Operation et PermissionMixin to django_rbac, rapatrier le modèle Operation
  • Description updated (diff)

Je sens que ce ticket va être suffisamment dodu, je vais gérer le déplacement de PermissionMixin à part dans #70135.

#4

Updated by Valentin Deniaud 4 months ago

20 builds pour en arriver là, d'abord essayer de migrer en changeant juste le nom des tables comme j'avais fait dans https://git.entrouvert.org/authentic.git/commit/?id=ad2d35fed53f8d207610e6aa1eb54930024f3271 et puis face à 1/ une fk à gérer 2/ des signaux post migrate à gérer 3/ des migrations inverses à gérer j'ai jeté l'éponge et fait une copie des données vers un nouveau modèle, mille fois plus simple et testable.

0001 pour bouger du code au préalable, sans que ce soit strictement nécessaire ça limite la dépendence de django_rbac envers a2_rbac, 0002 la migration.

#5

Updated by Valentin Deniaud 4 months ago

#6

Updated by Benjamin Dauvergne 4 months ago

  • Status changed from Solution proposée to En cours
En faisant comme cela on a perdu l'index d'unicité sur Permission operation/target_ct/target_id :
  • sur une instance avant :
                            Table « authentic_dev_publik_love.a2_rbac_permission »
       Colonne    |  Type   | Collationnement | NULL-able |                   Par défaut                   
    --------------+---------+-----------------+-----------+------------------------------------------------
     id           | integer |                 | not null  | nextval('a2_rbac_permission_id_seq'::regclass)
     target_id    | integer |                 | not null  | 
     operation_id | integer |                 | not null  | 
     ou_id        | integer |                 |           | 
     target_ct_id | integer |                 | not null  | 
    Index :
        "a2_rbac_permission_pkey" PRIMARY KEY, btree (id)
        "a2_rbac_permission_operation_id_3ad9aed4" btree (operation_id)
        "a2_rbac_permission_ou_id_a68ef755" btree (ou_id)
        "a2_rbac_permission_target_ct_id_519ab0ca" btree (target_ct_id)
        "null_ou_uniq_idx" UNIQUE, btree (operation_id, target_ct_id, target_id) WHERE ou_id IS NULL
    Contraintes de vérification :
        "a2_rbac_permission_target_id_check" CHECK (target_id >= 0)
    Contraintes de clés étrangères :
        "a2_rbac_permission_operation_id_3ad9aed4_fk_django_rb" FOREIGN KEY (operation_id) REFERENCES django_rbac_operation(id) DEFERRABLE INITIALLY DEFERRED
        "a2_rbac_permission_ou_id_a68ef755_fk_a2_rbac_o" FOREIGN KEY (ou_id) REFERENCES a2_rbac_organizationalunit(id) DEFERRABLE INITIALLY DEFERRED
        "a2_rbac_permission_target_ct_id_519ab0ca_fk_django_co" FOREIGN KEY (target_ct_id) REFERENCES django_content_type(id) DEFERRABLE INITIALLY DEFERRED
    Référencé par :
        TABLE "a2_rbac_role_permissions" CONSTRAINT "a2_rbac_role_permiss_permission_id_785cbab6_fk_a2_rbac_p" FOREIGN KEY (permission_id) REFERENCES a2_rbac_permission(id) DEFERRABLE INITIALLY DEFERRED
    

    après
    a2-test-migrate-django-rbac=# \d a2_rbac_permission
                                      Table « public.a2_rbac_permission »
       Colonne    |  Type   | Collationnement | NULL-able |                   Par défaut                   
    --------------+---------+-----------------+-----------+------------------------------------------------
     id           | integer |                 | not null  | nextval('a2_rbac_permission_id_seq'::regclass)
     target_id    | integer |                 | not null  | 
     ou_id        | integer |                 |           | 
     target_ct_id | integer |                 | not null  | 
     operation_id | integer |                 | not null  | 
    Index :
        "a2_rbac_permission_pkey" PRIMARY KEY, btree (id)
        "a2_rbac_permission_operation_new_id_0c34ce1f" btree (operation_id)
        "a2_rbac_permission_ou_id_a68ef755" btree (ou_id)
        "a2_rbac_permission_target_ct_id_519ab0ca" btree (target_ct_id)
    Contraintes de vérification :
        "a2_rbac_permission_target_id_check" CHECK (target_id >= 0)
    Contraintes de clés étrangères :
        "a2_rbac_permission_operation_id_3ad9aed4_fk_a2_rbac_o" FOREIGN KEY (operation_id) REFERENCES a2_rbac_operation(id) DEFERRABLE INITIALLY DEFERRED
        "a2_rbac_permission_ou_id_a68ef755_fk_a2_rbac_o" FOREIGN KEY (ou_id) REFERENCES a2_rbac_organizationalunit(id) DEFERRABLE INITIALLY DEFERRED
        "a2_rbac_permission_target_ct_id_519ab0ca_fk_django_co" FOREIGN KEY (target_ct_id) REFERENCES django_content_type(id) DEFERRABLE INITIALLY DEFERRED
    Référencé par :
        TABLE "a2_rbac_role_permissions" CONSTRAINT "a2_rbac_role_permiss_permission_id_785cbab6_fk_a2_rbac_p" FOREIGN KEY (permission_id) REFERENCES a2_rbac_permission(id) DEFERRABLE INITIALLY DEFERRED
    

Il manque null_ou_uniq_idx. Il faudrait supprimer les contraintes qui inclut operatoin_id sur Permission puis les remettre pour s'assurer que les index sont bien reconstruits. Je vais faire un diff entre dump complet du schéma avant et après pour voir un peu mieux ce que ça donne.

#7

Updated by Benjamin Dauvergne 4 months ago

D'un rapide coup d'oeuil je vois donc l'index précédent qui manque et aussi un "possible" souci sur le nom de la colonne operation qui est toujours référencé en operation_new_id, mais je ne sais pas si c'est grave vu que l'index existe, je ne pense pas que postgresql permettrait un index vers une colonne qui n'existe pas, mais peut-être faut-il aussi enlever la contrainte sur la FK avant de la renommer (db_constraint=False) (le nom est bon dans la colonne Définition mais pas dans la colonne "Colonne").

Ça a aussi l'effet de recréer un nouveau ContentType pour le modèle Operation et les permissions django.contrib.auth qui vont avec1 mais je ne pense pas qu'on s'en serve quelque part.

Le diff entre le contenu des tables permissions et operation avant après est vide, ça c'est ok.

1

authentic2_multitenant=# select * from auth_permission;
...
 272 | Can add operation                          |              69 | add_operation
 273 | Can change operation                       |              69 | change_operation
 274 | Can delete operation                       |              69 | delete_operation
 275 | Can view operation                         |              69 | view_operation

#8

Updated by Benjamin Dauvergne 4 months ago

  • Related to Development #70152: Lors de la génération des permissions d'un utilisateur, prendre en compte l'héritage entre modèles added
#9

Updated by Valentin Deniaud 3 months ago

Voilà avec retrait/ajout de la contrainte, pas d'avis sur operation_new_id mais comme c'est un simple RenameField généré par Django je me dis que ça doit être OK.

#10

Updated by Benjamin Dauvergne 3 months ago

  • Status changed from Solution proposée to Solution validée

Ne pas tagger tout de suite, qu'on joue un peu avec sur la plateforme de dev.

#11

Updated by Valentin Deniaud 3 months ago

  • Status changed from Solution validée to Résolu (à déployer)
commit cb9df4fbb2699e324f56ef2660639b462cbae040
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Tue Oct 11 16:10:48 2022 +0200

    a2_rbac: migrate existing operations to new model (#69902)

commit 3dab8ff21aed237decb8213281d2f6ecbfe0d8fe
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Oct 6 18:35:23 2022 +0200

    a2_rbac: move signal handlers from django_rbac (#69902)
#12

Updated by Transition automatique about 1 month ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF