update related cards/forms on digest change (#68427) #1241
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/68427-update-relations"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(stockage de brouillon)
b21bb6f69a
tob829d25c0b
b829d25c0b
to8b76d2b46d
8b76d2b46d
toad8c2b5213
ad8c2b5213
to7ffbb1ccfe
7ffbb1ccfe
tocaa1128381
@ -608,3 +608,3 @@
carddef.data_class().wipe()
resp = app.get(formdef.data_class().select()[0].get_url())
assert resp.pyquery('.field-type-item .value').text() == 'Xattr%sY' % baz_id
assert resp.pyquery('.field-type-item .value').text() == 'Yattr%sZ' % baz_id
Dans ce test on vérifiait le fallback sur la valeur stockée en _display en cas de suppression de la fiche; avec cette PR qui met à jour la valeur en _display ça ne marche plus pareil, on peut juste être content que la valeur s'affiche sans planter, ce qui était l'intention initiale de toute façon.
@ -634,6 +635,7 @@ def test_form_page_item_with_variable_data_source_prefill(pub):
def test_form_page_item_with_card_with_custom_id_prefill(pub):
create_user(pub)
CardDef.wipe()
FormDef.wipe()
Tests ajoutés récemment, il y a un carddata.store() exécuté avec les restes de reverse_relations sans rapport, il faut nettoyer correctement.
@ -1331,0 +1510,4 @@
carddata1.store()
formdata.refresh_from_storage()
assert formdata.data['1_display'] == 'view-card1-change1'
Vérification que sur une source de données sur une vue personnalisée, on obtient le résultat du digest template de la vue.
@ -1331,0 +1537,4 @@
carddef2.fields = [
ItemField(id='1', label='Test', varname='foo', data_source={'type': 'carddef:foo'}),
]
carddef2.digest_templates = {'default': 'bar-{{ form_var_foo }}'}
Un digest template qui reprend la valeur _display d'une autre fiche, un changement sur la valeur de cette autre fiche amènera donc un changement sur cette fiche, le test vérifie que ça cascade bien ainsi.
@ -1331,0 +1621,4 @@
# check it will have stopped once getting back to carddata2
carddata2.refresh_from_storage()
assert carddata2.data['2_display'] == 'card1 card2 card1 None'
Mais il faut éviter que la cascade culbute sans fin.
@ -1331,0 +1673,4 @@
assert formdata.data['1_display'] == 'bar-card1'
formdata.just_created()
formdata.store()
formdef.remove_self()
Il y avait une relation inverse vers ce formdef supprimé, il ne faudrait pas que la mise à jour se plante en allant le chercher.
WIP: update related cards/formds on digest change (#68427)to update related cards/formds on digest change (#68427)update related cards/formds on digest change (#68427)to update related cards/forms on digest change (#68427)@ -136,0 +140,4 @@
job = UpdateRelationsAfterJob(carddata=self)
if get_response():
job.store()
print(self, job.id)
un print qui traine
@ -136,0 +164,4 @@
update_related_seen = get_publisher()._update_related_seen
carddef = CardDef.get(self.kwargs['carddef_id'])
carddata = carddef.data_class().get(self.kwargs['carddata_id'])
et si le job est exécuté alors que la fiche en question a été supprimée ?
Ça serait vraiment pas de chance, mais en effet, j'ai géré la suppression de carddata ou carddef dans ce commit supplémentaire :
aaedccb39f
(il bouge un peu le dernier test, qui contenait un deuxième modèle de fiche pour rien).aaedccb39f
to737db3e1be