GitLab

version concernée: 3.28.0

récapitulatif: la fonction make_workflowable ne peut plus être utilisé avec add_workflow dans la version 3.28.0 (bien que dans la version 3.26.0 cela n'a pas posé problème), une erreur est remontée qui me dit qu'il manque les relations nécessaires missing workflow relations, see make_workflowable(EMailMessage)

détails:

>>> from cubicweb_risc.schema import EMailMessage
>>> EMailMessage.__relations__
[<date(Date)>, <subject(String)>, <body(String)>, <body_format(String)>]
>>> from cubicweb.schema import make_workflowable
>>> make_workflowable(EMailMessage)
>>> EMailMessage.__relations__
[<date(Date)>, <subject(String)>, <body(String)>, <body_format(String)>, <RelationDefinition 'custom_workflow' @7f05bba0a5f8>, <RelationDefinition 'in_state' @7f05bba0a2e8>, <RelationDefinition 'wf_info_for' @7f05bba0a940>]
>>> eschema = cnx.repo.schema["EMailMessage"]
>>> [r.type for r in eschema.subjrels]
['eid', 'identity', 'cwuri', 'body', 'body_format', 'creation_date', 'subject', 'date', 'modification_date', 'owned_by', 'created_by', 'is', 'cw_source', 'is_instance_of', 'sender', 'keyword']

côté cubicweb, si on appelle add_workflow, cela regarde dans subjrels pour vérifier si l'entité est workflowable

if ensure_workflowable:
    assert 'in_state' in eschema.subjrels, _missing_wf_rel(etype)
    assert 'custom_workflow' in eschema.subjrels, _missing_wf_rel(etype)
    assert 'wf_info_for' in eschema.objrels, _missing_wf_rel(etype)

dans cubicweb/server/migractions.py, donc il semble que eschema.subjrels n'est pas mis à jour correctement