-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move common functionality to destination base class #936
base: master
Are you sure you want to change the base?
Conversation
c39d564
to
55a2ff0
Compare
55a2ff0
to
5989b0a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #936 +/- ##
==========================================
- Coverage 77.36% 76.70% -0.66%
==========================================
Files 141 141
Lines 5548 5667 +119
==========================================
+ Hits 4292 4347 +55
- Misses 1256 1320 +64 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3b78212
to
7b8826c
Compare
0e23752
to
3131826
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just checked and we don't have a test for trying to PATCH update with medium being empty, that should be added, I think then it would be clearer if the changes work or not
We do have tests for when trying to change the medium that that will lead to an error
docs/integrations/notifications/writing-notification-plugins.rst
Outdated
Show resolved
Hide resolved
We are now way out of scope for a refactor. I guess the underlying problem is that we cannot lookup and change destinations of a specific media type directly, as part of the url of the endpoint. If we could, we would never need bother with media in the update-serializer. |
Yes, I agree, I can do this in another PR, but that would have to merged before this then, because it would show if the functionality is staying the same |
I don't think it is wise to stress with finishing this PR this week anymore, so start on the patch-PR next week. |
d1eb78c
to
97cc505
Compare
Originally posted by @johannaengland in #1118 (comment) |
I got stuff mostly working with this but the main problem is extracting errors to show in the related fields |
d329536
to
ee9eb86
Compare
38130e1
to
282b4d2
Compare
282b4d2
to
304367b
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sum comments
return {} | ||
|
||
@classmethod | ||
def raise_if_not_deletable(cls, destination: DestinationConfig) -> NoneType: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure None
should be used as return type over NoneType
, but this seems to be a relic from the past and not really introduced in this PR
|
||
@classmethod | ||
@abstractmethod | ||
def has_duplicate(cls, queryset: QuerySet, settings: dict) -> bool: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what @stveit mentioned in #1161 (review) could be avoided by simply updating the has_duplicate
method to also take the instance and check, that the entered data is a duplicate of another destination than the given instance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There need not exist an instance yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case instance can be empty and we know that if the settings exist somewhere else that it definitely is a duplicate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have that already, no? Smaller teaspoon, please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we have the check that assures that no duplicate destinations are posted, but as @stveit said in his review - this leads to that error showing when updating a destination without changing the settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this issue if the only problem I have with this PR. I have admittedly only tested on #1161 which isnt completely up to date with the changes in this branch
.. also make it easioer to validate the settings-field with a django form.
532c71e
to
0acb935
Compare
|
Updating existing destination is still buggy. It allows me to update either the email on its own or the label and email together. it does not allow me to only update the label, or just click update without making any changes. In the cases where it doesnt work this is the server log error:
|
Best reviewed per file.