✨(backend) signature backend new endpoint to get signature state of a signing procedure #925

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.

Validated order state is not used anymore.

Submitted state is not used anymore.

A test (probably randomized somewhere) was missing an object database refresh.

As we now have many test which contains asserts in loop, using subtests allows to continue the test to run, even if one of the assert fails.

This test was wrong with our new states. Subtest usage is introduced here. Also reverse path usage has been replaced by real path.

To ensure all cases are tested, even if one fails, subtest is added.

Order conditions and transitions were grouped by type. They are now grouped by usage, which make the code easier to read.

Order state pending transition was missing source targets. We can actually go from assigned, to_sign, to_save_payment_method, and to_sign_and_to_save_payment_method to pending.

Order state _post_transition_success was missing source states to create an enrollment.

Many things needs to be done before using the new states. Each of them are noted as TODO.

Contracts returned by the GenericContractViewSet queryset needs to be updated with the new state.

As TODOs are used temporarily, CI linting needs to ignore them. Also, convenient make tasks have been added.

As a test needs unique email generated, those provided by faker may collide.

As states changed, an error message needed to be updated accordingly.

Orders returned by the NestedOrderCourseViewSet queryset needs to be updated with the new state.

As states changed, an error message needed to be updated accordingly.

TODO added for triying to add more transitions to flow.update().

Order assign transition needs a billing address when creating the main invoice. If not present, the transition should fail.

Since user enrollment is not done at signature anymore, a test needs to be apdated accordingly.

A TODO was added to check if we need to set an enrollment in the LMS before unenrolling a user. As we need to keep it, the TODO is removed.

Order states stransitions related to payment weren't managed by flow.update. Now, in our code, everytime we want to change the order state, calling flow.update will suffice.

As all the states are managed in flow.update, we do not need to check if the current updated installment is the first or the last one.

As flow.assign is doing more than setting the order state to assign, and as it has to be called the first on an order lifetime, it has been renamed to init.

As we are simplifying the order state flow by signing contract before saving a payment method, the to_sign_and_to_save_payment state is no longer needed.

The order flowupdate method can be simplified.

For clarity in the order state flow, we extract the assign transition from the init method.

As the branch names have changed, the CI job needs to be updated as well.

From now on, the terms and conditions (CGV in French) must be specific to each organization. We can no longer use a global version for the entire platform. These terms will be included directly in the contract's context, so the Order model no longer needs to track user acceptance, as this will happen during contract signing. Fix #816

The terms and conditions will be written and stored in the contract definition body field. There's no need to prepare them separately for the contract context anymore. We've updated the generation of context by removing the key `terms_and_conditions` in the preparation. In this commit, we have also updated the contract definition html template for the section "Appendices". The use of `SiteConfig` to prepare terms and conditions in html is now deprecated.

Fix flow order tests after merging main.

Contracts needs to be signed as soon as possible by the organizations.

Our order tests often needs related objects to be created. A new order factory takes care of this, depending on the order state.

The order payment schedule needs to be generated before signing the contract.

The order contract needs to be created before the signature submission.

Once the student signs a contract, the order state needs to be updated.

Signature backends should return all contracts, except for the cancelled orders.

The contract is created on the fly when the learner ask to sign it so we could have case where the order has no contract but there is one to sign.

An endpoint is needed to bind a credit card to an order.

We need to force the credit card tokenization on payment. #801 (comment)

As we now allow more order states for enrollments, we use them to determine the enrollment mode used.

We will always use installments for all orders.

Fix tests after merging main.

As we will always use installments for payments, all payment methods should not have an optional installment parameter, but a mandatory one.

Amounts conversions to centimes using regular python types can lead to errors. Using Stockholm avoids problems.

As we have new order states, we need to use them in admin frontend.

As we want to display payment schedule in our admin frontend, we need to add it to the admin api.

We want to display the payment schedule in orders.

A user can tokenize a card outside any payment process and in this case no order information is receivend by the handle_notification endpoint. We have to deal with this case to create a card just linked to user and without order information

The payment debug view has not been updated since backend payment signature has changed. This commit fix it and add a new case where we want to tokenize a card directly for a user without order information.

When the due date has come, the task `process_today_installment` now verifies if there are previous installments on the order that require a payment. Now, the task will trigger a payment for the installments that are in the past that are unpaid. Fix #792

Currently, we are storing order images (organization logo) into json field as base64 encoded string. This is weird as it takes a lot of space in database then we duplicate images in each certificate where they are used. That's why, we decide to stop that and store Order images in a DocumentImage.

As the signature backend may take some time to validate a signature, a new state is added to properly wait for it.

Real behavior of signature provider is to set the submitted_for_signature_on when asking for a signature link, and to set student_signed_on when handle_notification is called.

When a signature is refused, we need to update the order state.

We recently remove the automatic update of contract when an API consumer request an invitation link with the dummy signature backend. That means now, the API consumer has to call manually the notification endpoint to confirm the signature but some information where missing to update properly the contract, so we complete the invitation_link method to bind missing information.

We recently add a new order state: "signing". But we do not update the admin application accordingly, so order views were broken when a signing order must be displayed.

Currently, an order in pending state is able to transition to pending_payment once no installment has been refused. That means we are able to transition to this state order to which we never try to pay an installment that is weird. Indeed, only orders with the first installment paid and all others installment not refused should be allowed to transition to pending_payment state

The `has_submitted_contract` returns True if the related Order has contract with field `submitted_for_signature_on` not None

Until a contract is submitted, it should not be possible to transition back to to_sign state.

The list credit card endpoint now returns first the main credit card then all others credit cards sorted by descending creation date.

We have to add a cronjob in the tray to manage the process_payment_schedule management command.

For product with a price less than 150, payment schedule should contain only one installment.

Currently, some logic were missing to be able to generate a payment schedule for a certificate product (which have no target_courses)

The nested endpoint `courses/<course_code>/orders/` should return all order in binding states. Indeed, course manager should be able to list all learners who have subscribed to their trainings.

Currently, the env configMap volume is not mounted but we need it to be able to access to S3 Storage.

The extension of the file to declare the cronjob process payment schedule was wrong

With the new workflow, the order field has_consent_to_terms has been deprecated so we can remove it from the order detail view in the BO application

Currently, the payment schedule was generated on the signature submit. But this was weird as some product can have no contract and in this case, no payment schedule is generated. So in order to support this kind of product, we move the payment schedule generation logic on pending transition success.

`find_today_installments` currently retrieve only installments which have a due_date sets to today. Instead we would like to retrieve all installements which are due to payment today.

We have added a new uniqueness constraint into the model Address. A user or an organization can only have 1 address with the same values for the fields `address`, `postcode`, `city`, `country`, `first_name`, `last_name`. Fix #873

The payment schedule dates were wrong when the withdrawal date was after the session start date.

For every installment paid in a payment schedule, we trigger an email with the information about the last payment done. We needed to prepare a new MJML template for the email that is sent to the user.

When all installments are paid on the order's payment schedule, we needed to prepare a new MJML template for the email that is sent to the user summarizing all the installments paid and also confirming that the user has successfully paid every step on the payment schedule.

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

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.

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

✨(backend) signature backend new endpoint to get signature state of a signing procedure #925

✨(backend) signature backend new endpoint to get signature state of a signing procedure #925

Commits on Sep 19, 2024

Commits on Sep 20, 2024

✨(backend) signature backend new endpoint to get signature state of a signing procedure #925

Are you sure you want to change the base?

✨(backend) signature backend new endpoint to get signature state of a signing procedure #925

Commits on Sep 19, 2024

Commits on Sep 20, 2024