Skip to content
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

Refactor payments module to apply plugin mechanism consistently #4921

Merged
merged 2 commits into from
Dec 16, 2024

Conversation

sergei-maertens
Copy link
Member

Part of #3457 - doing the refactor before making the required changes

All other modules operate on the idea that the generic code populates the plugin options from the generic information and the specified options serializer, which allows plugins to be generically typed and not needing to perform additional input validation or conversion from the raw JSON data for the options to the Python/Django objects that are easier to work with.

This does change the public API of the registry/plugins to take an extra argument, but enables us to apply static type checking (which already reveals some problems) and simpler plugin code.

Checklist

Check off the items that are completed or not relevant.

  • Impact on features

    • Checked copying a form
    • Checked import/export of a form
    • Config checks in the configuration overview admin page
    • Problem detection in the admin email digest is handled
  • Release management

    • I have labelled the PR as "needs-backport" accordingly
  • I have updated the translations assets (you do NOT need to provide translations)

    • Ran ./bin/makemessages_js.sh
    • Ran ./bin/compilemessages_js.sh
  • Dockerfile/scripts

    • Updated the Dockerfile with the necessary scripts from the ./bin folder
  • Commit hygiene

    • Commit messages refer to the relevant Github issue
    • Commit messages explain the "why" of change, not the how

…ently

All other modules operate on the idea that the generic code populates
the plugin options from the generic information and the specified
options serializer, which allows plugins to be generically typed and
not needing to perform additional input validation or conversion from
the raw JSON data for the options to the Python/Django objects that
are easier to work with.

This does change the public API of the registry/plugins to take an
extra argument, but enables us to apply static type checking (which
already reveals some problems) and simpler plugin code.
Copy link

codecov bot commented Dec 16, 2024

Codecov Report

Attention: Patch coverage is 88.70968% with 7 lines in your changes missing coverage. Please review.

Project coverage is 96.59%. Comparing base (753691c) to head (e9aa4d7).

Files with missing lines Patch % Lines
src/openforms/payments/services.py 42.85% 3 Missing and 1 partial ⚠️
src/openforms/payments/views.py 66.66% 3 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #4921   +/-   ##
=======================================
  Coverage   96.58%   96.59%           
=======================================
  Files         757      758    +1     
  Lines       25783    25798   +15     
  Branches     3390     3390           
=======================================
+ Hits        24902    24919   +17     
+ Misses        616      613    -3     
- Partials      265      266    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Rather than just type-checking some files, we are close enough to
type check most of the package and instead skip some files/subpackages
with known (but not critical) type checking issues.

Here and there we need to suppress some errors because the Django ORM
magic is too much for Pyright.
@sergei-maertens sergei-maertens force-pushed the feature/3457-refactor-payment-plugins branch from dbdba94 to e9aa4d7 Compare December 16, 2024 08:40
@@ -127,7 +126,6 @@ def expected_parameters(self):
class FormAdmin(
FormioConfigMixin,
RegistrationBackendFieldMixin,
PaymentBackendChoiceFieldMixin,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

irrelevant/unused because we only support the React-based change form page.

return_method = "GET"
webhook_method = "POST"
configuration_options = EmptyOptions
configuration_options: type[serializers.Serializer] = EmptyOptions

# override

def start_payment(
self,
request: HttpRequest,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this stays HttpRequest because it's called outside of DRF views too

) -> PaymentInfo:
raise NotImplementedError()

def handle_return(
self, request: HttpRequest, payment: "SubmissionPayment"
self,
request: Request,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to DRF request because plugin code is accessing DRF-specific properties that don't exist on HttpRequest

@sergei-maertens sergei-maertens merged commit c07912d into master Dec 16, 2024
31 of 33 checks passed
@sergei-maertens sergei-maertens deleted the feature/3457-refactor-payment-plugins branch December 16, 2024 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants