Org Web Adapter

Editing hungryroot/jira/be_7351_add_original_points_nullability_support_to_createtestcustomerview_for_edge_case_testing.org

:PROPERTIES:
:ID:       facd89f5-c976-429b-9661-77806d0b1c62
:END:
#+title: BE-7351 Add original_points nullability support to CreateTestCustomerView for edge-case testing

- source :: https://hungryroot.atlassian.net/browse/BE-7351
- tags   :: [[id:3a477c02-e26d-40f7-a719-0aa1cd169dd8][Hungryroot API Project]] 
- epic   :: [[id:86327fb4-0f66-4bc6-9068-c414cea77042][EP-411 Eng Parking Lot]]
- sprint :: [[id:9821b605-4d59-432e-b15d-95999d25cc39][HR BE Sprint 106]]
- status :: [[id:4d41d978-e56f-45c1-88d1-e2c76510972e][Status - Complete]]

* Tasks
** DONE Add nullability support to the create test user endpoint for original_points :work:hungryroot:project:ep411:be7351:sprint106:cursor:
:PROPERTIES:
:ID:       5500fab3-a26d-bcb8-29da-6f8e955d49f6
:END:
* Description
The CreateTestCustomerView in test_automation/views/create_test_customer.py
creates test customers with configurable settings for QA. Delivered orders are
created via DeliveredOrderFactory with with_box_contents, which fills order
details through BoxContentFactory.fill_box(). In this flow,
OrderDetail.original_points is always populated from product.points.

However, in production, original_points is a nullable DecimalField on
OrderDetail (app/models/order_detail.py:63) and real users can have null values.
Code that reads original_points (e.g. discount_percentage,
points_after_discount, swap/short logging in Order) may behave differently when
original_points is null vs populated. Our test data never reflects this edge
case.

** Problem

All test-generated orders have original_points set on every OrderDetail, which
doesn't reflect the variety seen in production. It is unrealistic to manually
test every optional/nullable property, and there is currently no mechanism in
the test endpoint to generate data that exercises these edge cases.

** Proposed Implementation

Two complementary approaches:

1. Direct original_points control

Add an optional nullify_original_points boolean (default false) to the
serializer. When true, after delivered orders are created, set original_points =
None on some or all OrderDetail rows for that customer's orders. This gives
testers a direct toggle to reproduce the production edge case.

2. Broader "edge case mode" (stretch goal)

Consider a more general edge_case_mode or nullify_fields parameter that randomly
nullifies optional/nullable fields on generated test data to better simulate
real-world variety. This would be a more scalable solution for catching
null-safety issues across many fields, not just original_points. This could be
scoped as a follow-up ticket if the direct approach above is sufficient for now.

** Relevant Code

OrderDetail.original_points - app/models/order_detail.py:63 (nullable DecimalField)

OrderDetail.discount_percentage - reads original_points, will error if null (app/models/order_detail.py:94-98)

OrderDetail.points_after_discount - reads original_points (app/models/order_detail.py:101-109)

Order swap/short logging - serializes original_points with null checks (app/models/order.py:2680, 2722, 2749)

DeliveredOrderFactory + BoxContentFactory - always populates original_points from product.points

create_delivered_orders_for_test_customer task - test_automation/tasks.py

** Acceptance Criteria

+ [ ] New optional boolean field (e.g. nullify_original_points) added to TestCustomerCreationSerializer
+ [ ] When enabled, delivered orders are created with original_points = None on their OrderDetail rows
+ [ ] Default behavior (field omitted or false) is unchanged - original_points is populated normally
+ [ ] Field is documented in API schema via help_text
+ [ ] Unit tests cover both the default and nullified scenarios