Skip to content

feat(spp_drims): Donations review — creation, receipt, inspection and follow-up - #414

Open
emjay0921 wants to merge 11 commits into
19.0from
fix/1076-drims-donations-review
Open

feat(spp_drims): Donations review — creation, receipt, inspection and follow-up#414
emjay0921 wants to merge 11 commits into
19.0from
fix/1076-drims-donations-review

Conversation

@emjay0921

Copy link
Copy Markdown
Contributor

Why is this change needed?

OP#1076 (DRIMS - Full review - Donations) and all four of its children have passed QA — this raises the PR for that work, per the flow of opening PRs once QA signs off.

Ticket Status
OP#1076 DRIMS - Full review - Donations Test pass
OP#1055 Remove "Add a line" on the following pages Test pass
OP#1058 No tracking or follow-up workflow for non-accepted items Test pass
OP#1108 Fix "Add a product" when creating a new donation Test pass
OP#1163 Launch wizard when clicking "Mark Received" Test pass

What is in here

  • Donation creation and lifecycle UX reworked — the form leads with what the donor pledged, columns appear as the donation progresses (Pledged in draft, Received and Variance once announced, Condition and Action after inspection), and a donation now requires at least one item before it can be saved.
  • Line entry is bounded by state (OP#1055) — items can be added while the donation is draft or announced and not after, so nobody can append product-less rows to an already-received donation.
  • Inline-created products are storable (OP#1108) — a product quick-created from the donation line now defaults to a storable Good, so it actually tracks in inventory instead of silently never appearing in Stock on Hand.
  • Received quantities are entered through a wizard (OP#1163) — "Mark Received" opens a form for what actually arrived, rather than assuming the pledged quantity.
  • Non-accepted items have a follow-up workflow (OP#1058) — items returned, disposed of or quarantined at inspection are tracked to resolution in their own table, instead of disappearing from the donation.

New unit tests

Covering the lifecycle guards, the receive wizard, the follow-up states on non-accepted items, and the form structure. spp_drims runs 285 tests.

Unit tests executed by the author

On the merged branch:

spp_drims    0 failed, 0 error(s) of 285 tests

./spp lint --all-files clean.

How to test manually

  1. Create a donation. Add a line must be available on the empty items table, and the donation must refuse to save with no items.
  2. Take it to Announced, then Mark Received — the wizard collects the arrived quantities and the Variance column shows the difference against Pledged.
  3. Inspect it, marking some items for return or disposal. Those appear under Items Not Accepted for Stock with a follow-up state, and not in the main items table.
  4. Stock the remainder and confirm only accepted items enter inventory.

Related links

https://openspp.openproject.com/work_packages/1076

Reviewer notes

Two rules in here close a door on each other if either is wrong, which is worth knowing while reviewing. A donation cannot be saved without at least one item, and the items table is state-bounded. During QA a CSS rule intended to hide Odoo's blank filler rows also hid the "Add a line" control — so there was no way to add an item and no way to save without one, and a donation could not be created at all. Fixed in 4751c7ee; the filler rows are now matched by having no class, which is what actually distinguishes them from the add row.

The branch was brought up to date by merging 19.0, not rebasing, since it was already published.

emjay0921 added 10 commits July 15, 2026 10:26
Adds a Draft start stage to the donation lifecycle
(Draft -> Announced -> Received -> Inspected -> Stocked) with a
"Mark Announced" action, and reshapes the form around it:

- Cancel renamed to "Cancel Donation".
- Donor limited to DRIMS organisations whose role is Donor; donations
  cannot be recorded against a closed incident (domain + constraint).
- At least one item is required to save; the line Description field is
  removed and Pledged must be entered (no default, must be > 0).
- Line columns appear progressively: Received (manual, mandatory) and
  Variance from Announced, Condition and Action from Inspected; Expiry
  Date only when product_expiry is installed.
- Received quantities are entered manually instead of being auto-copied
  from Pledged.
- Once inspected, items with a non-accept disposition are listed in a
  separate "Items Not Accepted for Stock" table.
Donation items can only be added or removed while the donation is in
draft. The line table is read-only from the received state onward so the
"Add a line" row no longer appears once a donation has been received,
and donation-line create/unlink are guarded at the model level. The
inspection wizard's split rows opt out of the guard so splitting an
inspected donation still works.
A product added through "Add a line" on a donation was created
non-storable, so it never tracked in inventory and did not appear in
Stock on Hand. The donation-line product field now defaults inline
product creation to a storable Good (type consu, Track Inventory on).
Items excluded from stock at stocking time (Return / Dispose / Quarantine)
are now tracked to resolution instead of only being mentioned in a toast.

- Donation lines gain a disposal status (Pending -> Resolved) with resolved
  date, user and notes; stocking seeds the excluded lines to Pending.
- A 'Mark Resolved' action records who/when and posts an audit note to the
  donation's chatter for accountability.
- A dedicated 'Non-Accepted Items' list + menu under Monitoring lists the
  excluded items (default Pending), filterable and groupable by action; the
  donation form's 'Items Not Accepted for Stock' table shows the disposal
  status and a resolve button.
…ons-review

# Conflicts:
#	spp_drims/__manifest__.py
#	spp_drims/security/ir.model.access.csv
A new donation offered no way to add items. The stylesheet that hides Odoo's
blank filler rows on the donation tables excluded
.o_field_x2many_list_row_add from the rows it hid, on the assumption that
class sits on the <tr>. In Odoo 19 it is on the <td> and the row itself is
<tr class="d-print-none">, so the exclusion never matched and the rule hid
the "Add a line" row along with the fillers.

This was worse than being unable to add items. OP#1076 also requires at
least one item before a donation can be saved, so with the add row hidden
there was no way to satisfy that rule: a donation could not be created at
all. The two rules closed the door on each other.

Match the fillers by having no class instead, which is what actually
distinguishes them - data rows carry o_data_row and the add row carries
d-print-none. If Odoo ever gives fillers a class the rule stops applying and
the blank rows come back, which is a cosmetic regression rather than a form
nobody can enter data into.

Also switches the donation line's hidden quantity field from invisible to
column_invisible. Inside a list the former blanks the cells but still renders
the column, which is why an empty "Quantity" column sat between Pledged and
Unit.
@codecov

codecov Bot commented Aug 13, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.45763% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.77%. Comparing base (64e6b31) to head (108e826).

Files with missing lines Patch % Lines
spp_drims/models/donation.py 97.87% 1 Missing ⚠️
spp_drims/models/donation_line.py 97.05% 1 Missing ⚠️
spp_drims/wizard/receive_wizard.py 96.15% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             19.0     #414      +/-   ##
==========================================
+ Coverage   72.66%   72.77%   +0.10%     
==========================================
  Files         329      330       +1     
  Lines       24298    24407     +109     
==========================================
+ Hits        17655    17761     +106     
- Misses       6643     6646       +3     
Flag Coverage Δ
spp_base_common 91.07% <ø> (ø)
spp_drims 82.97% <97.29%> (+0.72%) ⬆️
spp_drims_sl_demo 68.75% <100.00%> (-0.26%) ⬇️
spp_programs 65.27% <ø> (ø)
spp_registry 87.22% <ø> (+0.07%) ⬆️
spp_security 69.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
spp_drims/models/constants.py 100.00% <100.00%> (ø)
spp_drims/wizard/__init__.py 100.00% <100.00%> (ø)
spp_drims/wizard/inspection_wizard.py 91.20% <100.00%> (ø)
spp_drims_sl_demo/wizard/drims_demo_generator.py 68.55% <100.00%> (-0.26%) ⬇️
spp_drims/models/donation.py 97.03% <97.87%> (+0.12%) ⬆️
spp_drims/models/donation_line.py 93.18% <97.05%> (+6.51%) ⬆️
spp_drims/wizard/receive_wizard.py 96.15% <96.15%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

The SL demo generator could no longer produce donations. It assumed a
donation is created in "announced" and that Mark Received copies the pledged
quantity, both of which OP#1076 changed: donations now start in draft, and
the received quantity is entered by hand and required before a donation can
be marked received.

Walk from draft with an explicit announce step, and record demo donations as
arriving in full so the receive step has quantities to work with.

Caught by CI, not locally: spp_drims_sl_demo is two levels down the
dependency chain from spp_drims and a spp_drims-only run cannot see it.
@emjay0921
emjay0921 marked this pull request as ready for review August 13, 2026 09:17
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