diff options
| author | Stephen Finucane <stephen@that.guru> | 2020-10-04 12:03:19 +0100 |
|---|---|---|
| committer | Stephen Finucane <stephen@that.guru> | 2020-12-13 18:22:12 +0000 |
| commit | 8092f8f4f59ea5581180a13994eb090d24394206 (patch) | |
| tree | ecce500c53dd4f41bd7c839141ed489779309b14 /patchwork/api/event.py | |
| parent | 87e9f510b2670d199ab2930900c357c3ecda761d (diff) | |
| download | patchwork-8092f8f4f59ea5581180a13994eb090d24394206.tar patchwork-8092f8f4f59ea5581180a13994eb090d24394206.tar.gz | |
tests: Add tests for 'patch-relation-changed' events
This event is rather odd. If you have two patches then the way a
relation is created is by creating a 'PatchRelation' instance and then
setting the 'related' attribute on the first patch followed by the
second patch. Because the event uses the 'Patch' model's 'pre_save'
signal, we'll only see events for the patch being currently saved. This
means no event will be raised for the first patch and only one event,
the one for the second patch, will be raised when the second patch is
being added to the relationship.
In hindsight, the structure of the event is off. We should have had
something like a 'patch-added-to-relationship' and a
'patch-removed-from-relationship' event, both with the same fields:
'project', 'actor', 'patch' and 'related', the latter of which would
have listed all of the _other_ patches in the relationship. Sadly, this
is an API change which means we can't do it now. We may well wish to do
so in the future though.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Diffstat (limited to 'patchwork/api/event.py')
0 files changed, 0 insertions, 0 deletions