Tidy up issues observed post MVP/Version 1 deploy 16/02/24:
Assumptions or Pre-Requisites:
Deploy has completed
Some of these issues seen in both DEV and PROD
Acceptance Criteria: (Must be completed before task is moved to 'Done')
[ ] Need to resolve these issues for Version 1 deploy to be considered a success
Tasks
[x] Task1 * some functionality acting differently in PROD than DEV: some strange behaviour with duplicate orders created within the PROD database, however these only have been sent to Stripe once. DONE? On investigation, this is becuase in checkout/views.py when loading the order form, order.stripe_pid has been accidentally mistyped (must have happened when editing something else, as this as previously working). Therefore the stripe_pid wasn't getting written to the order and the webhook was creating a backup (incomplete) order.
[x] Task2 The above issue alerted me that the orders created by the webhook are not as 'complete' as those created by the checkout order method - orderline is missing price & category, order is not populated with Userid, order is not populated with any of the newly-added fields that don't have defaults (STATUS populates with default ORDERED; order_delviery_method populates with the default value REGPOST rather than the value entered on the form, order.promised_ship_date populates with ....).... so note to self, if i want any of these to populate from the checkout form i'll also have to write them to the basket/ ensure they are picked up by the webhook if order is created within the webhook rather than the checkout basket.)
DONE 21/02/24: - the webhook will not be a perfect fall-back for th eorder, as not all values are passed t Stripe's payment intent - so fore example the delivery method will not be correctly assigned (but it will default to REGPOST which is most of the orders, and will have a delivery addrss of Goldmark if its a COLLECT order. The order ship date will not be correctly calculated, the status will not be loaded, but will default to ORDERED in any case. Deployed 21/02/24, let's see how this works in practice.
[x] Task3 Also some strange behaviour on checkout screeen where it doesnt seem to be defaulting from, or updating to, the UserProfile object).
Before changing task status to 'Review' or 'Done' please provide comment (and screenprints if appropriate) as documentary evidence of task completion
EPIC: #7
Tidy up issues observed post MVP/Version 1 deploy 16/02/24:
Assumptions or Pre-Requisites:
Acceptance Criteria: (Must be completed before task is moved to 'Done')
Tasks
[x] Task1 * some functionality acting differently in PROD than DEV: some strange behaviour with duplicate orders created within the PROD database, however these only have been sent to Stripe once. DONE? On investigation, this is becuase in checkout/views.py when loading the order form, order.stripe_pid has been accidentally mistyped (must have happened when editing something else, as this as previously working). Therefore the stripe_pid wasn't getting written to the order and the webhook was creating a backup (incomplete) order.
[x] Task2 The above issue alerted me that the orders created by the webhook are not as 'complete' as those created by the checkout order method - orderline is missing price & category, order is not populated with Userid, order is not populated with any of the newly-added fields that don't have defaults (STATUS populates with default ORDERED; order_delviery_method populates with the default value REGPOST rather than the value entered on the form, order.promised_ship_date populates with ....).... so note to self, if i want any of these to populate from the checkout form i'll also have to write them to the basket/ ensure they are picked up by the webhook if order is created within the webhook rather than the checkout basket.) DONE 21/02/24: - the webhook will not be a perfect fall-back for th eorder, as not all values are passed t Stripe's payment intent - so fore example the delivery method will not be correctly assigned (but it will default to REGPOST which is most of the orders, and will have a delivery addrss of Goldmark if its a COLLECT order. The order ship date will not be correctly calculated, the status will not be loaded, but will default to ORDERED in any case. Deployed 21/02/24, let's see how this works in practice.
[x] Task3 Also some strange behaviour on checkout screeen where it doesnt seem to be defaulting from, or updating to, the UserProfile object).
Before changing task status to 'Review' or 'Done' please provide comment (and screenprints if appropriate) as documentary evidence of task completion