✨(backend) signature backend new endpoint to get signature state of a signing procedure #925
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wilbrdt
reviewed
Sep 13, 2024
kernicPanel
reviewed
Sep 17, 2024
There was a problem hiding this comment.
I think we should abstract the progression values away.
This is related to current Lex Persona API, and may change.
Also, we just want to know who already signed.
Maybe use a function named get_signature_state which returns something like {"student": bool, "organization": bool} ?
WDYT ?
...backend/joanie/tests/signature/backends/lex_persona/test_get_signature_procedure_progress.py
Outdated
Show resolved
Hide resolved
|
I think before merging this endpoint, we should try to fix the |
jonathanreveille
force-pushed
the
dev_/signature_provider_backend_retrieve_workflow_details
branch
from
b91cbaf
to
4579a17
Compare
jonathanreveille
changed the title
kernicPanel
reviewed
Sep 19, 2024
New order states are needed for the new sales tunnel: - ORDER_STATE_ASSIGNED - ORDER_STATE_TO_SAVE_PAYMENT_METHOD - ORDER_STATE_TO_SIGN - ORDER_STATE_TO_SIGN_AND_TO_SAVE_PAYMENT_METHOD
…signment" This reverts commit ce938db.
This reverts commit 35893fc.
With the new sale tunnel, we need to assign an organization directly on order creation.
As order submit endpoint will be removed, we set ProductTargetCourseRelation directly on order creation.
As a main invoice is created at the first payment scgedule installment, we create it at order creation, and use it to store the billing address.
We want to store the chosen credit card in an order, and use it to trigger scheduled payments.
As pending order state will be deleted, the abort endpoint will be useless.
As payment process is being rewritten, the submit endpoint will be useless.
As validate order state will be deleted, the validate endpoint will be useless.
As the submit transition will be removed, the code executed in it is removed, and the tests are accordingly modified.
As the validated order state will not be used anymore, its usage has been removed.
As order.submit content has been removed, we can delete it.
As some order flows has been removed, we can delete them.
As the unused states have been removed, we have to add a database migration to replace them. Strings are used here to allow us to delete them from our enums module.
Pending order state transition will not be used anymore.
To ease the life of our fellow developers, we have created a debug view to see the layout and how the email is rendered for installment payment that are paid.
To ease the life of our fellow developers, we have created a debug view to see the layout and how the email is rendered for when all the installments are paid on the payment schedule for the user.
Once an installment is paid, we now send an email with the data on the payment made by the user. There are 2 different email templates, one is used when 1 installment is paid, an the other template is used when all the installments are paid on the payment schedule. Fix #862
On enrollment order resource, our api consumer needs to be able to retrieve payment schedule information so we update the OrderLightSerializer to add this field.
When an installment debit has failed in a payment schedule, we trigger an email with the information. First, we need to create a new MJML template for this situation.
For our fellow developers, we have created a debug view to checkout the layout and the rendering of the email that is sent when an installment has failed to be debited.
Once an installment debit has been refused, we send an email with the data about the failed payment in the payment schedule of the order. Fix #863
The `OrderPaymentScheduleDecoder` was returning a string representation of the `due_date` instead of a `datetime.date` object. The same way, it was returning a string representing the `amount` instead of a `Money` object. This behavior complicated comparisons and operations, as handling both strings and money and date objects increased the complexity. To simplify date and money handling and ensure consistency, a cast was added to the decoder, converting the string from the database into a `datetime.date` object for `due_date`, and the `amount` into a `Money` object. This change ensures that `due_date` is always a `date` object, and `amount` is always a `Money` object. It makes it easier to work with throughout the codebase. For our fellow developers, they can now freely pass strings to prepare their payment schedule with the `OrderFactory` or the `OrderGeneratorFactory` in tests, where for the fields `due_date` and `amount`, they both will be casted to their respective types after being created.
When an installment debit will occur in the payment schedule of an order, we should trigger an email mentioning when the next debit will be and its amount. First, we need to create a new MJML template for the reminder of the next installment payment debit.
For our fellow developers, we have created a debug view to checkout the layout and the rendering of the reminder email that is sent when the next installment will be debited.
The new django command `send_mail_upcoming_debit` will retrieve all 'pending' state installments on orders payment schedules and send a reminder email with a certain amount of days in advance (configured with `JOANIE_INSTALLMENT_REMINDER_PERIOD_DAYS`) to the order's owner notifying them that they will be debited on their credit card. Fix #864
We have to add a cronjob in the tray to manage the `send_mail_upcoming_debit` management command.
Now a credit card is linked to an order, we want to display that in our back office application to we bind this data the AdminOrderSerializer.
Add an util to transform a number into a string. If the value is less than 10, it prefix it with a `0`
Now Joanie admin api returns credit card related to the order.
Add a presentational component to render credit card information
If an order has a payment method, we display it within the payment schedule section otherwise a warning alert message is displayed.
We have added in post transition success to 'pending' state of an order that will trigger a payment to let the user have access to the course immediately when the installment's due date is on the current day. This case may happen when we generate the payment schedule and if the course has already started, the 1st installment due date of the order's payment schedule will be set to the current day. Since we only debit the next night through a cronjob, we need to be able to make the user pay to have access to his course, and avoid that the has to wait the next day to start it. Fix #913
jonathanreveille
force-pushed
the
dev_/signature_provider_backend_retrieve_workflow_details
branch
3 times, most recently
from
f25689f
to
e7b5e45
Compare
Instead of waiting for the webhook that a document has been signed from the signature provider (the cause would be a latency to send us the notification event), we have decided to add a new endpoint on the backend signature provide to get the information if whether the student or the organization have signed the document. The new method returns a dictionary with boolean value that informs the progression of signing procedure of a document.
jonathanreveille
force-pushed
the
dev_/signature_provider_backend_retrieve_workflow_details
branch
3 times, most recently
from
ab21d9e
to
c4dd411
Compare
For the serializer client ContractLightSerializer, whether the notification from the signature provider takes some time to let us know that the student has signed, when the viewset is called, it will trigger our serializer method that will check if the student has finished signing his part on the document. That allows the frontend to get the latest information when the student gets to his dashboard of course orders.
jonathanreveille
force-pushed
the
dev_/signature_provider_backend_retrieve_workflow_details
branch
from
c4dd411
to
7c2897b
Compare
jbpenrath
force-pushed
the
dev
branch
2 times, most recently
from
07e01cf
to
2594fc0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
It seems like the webhook notifications for signatures may take some time to tell us that a document has been signed.
This will allow us to know directly the progress instead of waiting.
To explain more in details :
Lex Persona updates the workflow concerned as soon as it gets the signature of the student. This is the reason why we've added this new endpoint which will allow us to see the progression of a signature procedure. With some experience with the signature provider that we use in production, we cannot depend on the speed of the webhook that is sent from Lex Persona to us. It becomes urgent that we need another way to verify the progression of a signing procedure.
We made an utility method that translates those integer values as a dictionary like the following example :
{"student": False, "organization": False}: nobody has signed.{"student": True, "organization": False}: student has signed only.{"student": True, "organization": True}: student and organization have signed.Those values are retrieved from the response given from LexPersona of a signing procedure with the attribute
isFinishedthat has a boolean value for each step.Proposal