spree-bank_payments 5.1.0 → 5.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +24 -0
- data/README.md +8 -0
- data/app/views/spree/bank_payments/admin/_order_panel.html.erb +11 -2
- data/lib/spree/bank_payments/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 853a5591445f34c158831ce573209a2d0bd300c01f107576eecbab2d5c1336d2
|
|
4
|
+
data.tar.gz: 33614d35672725463dbbb13c1a70398d843135cc824e76ec4e3b3f8ff8b843e9
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: e35bb75965fe3896265cec76c1f93f117e52b23e2058d9105fdfef973a0c859fa3c0be94ec9842fa023c01f400f4714208ef19289f7d4f8a751918b77082f3d0
|
|
7
|
+
data.tar.gz: 0d4456c3a1f35e6d8a28e7dbe6b54be40b78dd9ac1919b9b2c919e6294e31f6f0d6c4d24f984873f5df7177ec1cc126794aab6cee59ef31ab76effde706eed9f
|
data/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,30 @@
|
|
|
2
2
|
|
|
3
3
|
All notable changes to this project are documented in this file.
|
|
4
4
|
|
|
5
|
+
## 5.1.1
|
|
6
|
+
|
|
7
|
+
### Fixed
|
|
8
|
+
|
|
9
|
+
- The admin order panel badged a **superseded** bank-transfer session as
|
|
10
|
+
"Expired". A session is superseded (canceled) when the order was settled by
|
|
11
|
+
another payment method, and its `expires_at` is usually already in the past —
|
|
12
|
+
so testing the time-based `expired?` predicate first labelled a card-paid
|
|
13
|
+
order as expired. The badge now branches on session **status**, and shows
|
|
14
|
+
"Superseded" for that case.
|
|
15
|
+
|
|
16
|
+
The same change fixes a second misreport: a *pending* session past its expiry
|
|
17
|
+
that the sweeper has not reached yet is still matched by `.open`, so a
|
|
18
|
+
transfer can still be auto-applied to it. It now correctly reads "Awaiting
|
|
19
|
+
transfer" rather than "Expired".
|
|
20
|
+
|
|
21
|
+
### Documentation
|
|
22
|
+
|
|
23
|
+
- The manual "record a received transfer" form derives a transfer's identity
|
|
24
|
+
from the values entered, which makes resubmission safe but also means two
|
|
25
|
+
genuinely separate transfers matching on every recorded field are treated as
|
|
26
|
+
one. The README said only the first half; it now says both, with guidance for
|
|
27
|
+
recording a real duplicate payment.
|
|
28
|
+
|
|
5
29
|
## 5.1.0
|
|
6
30
|
|
|
7
31
|
**The bank-transfer discount is now tax-aware.**
|
data/README.md
CHANGED
|
@@ -58,6 +58,14 @@ at `/admin/bank_transfers`. That screen is the operational heart of the gem:
|
|
|
58
58
|
from what you typed, so a resubmission is recognised as the same transfer
|
|
59
59
|
and nothing is credited twice.
|
|
60
60
|
|
|
61
|
+
The same derivation has a flip side. Two genuinely separate transfers that
|
|
62
|
+
match on every recorded field — payment method, amount, currency, reference,
|
|
63
|
+
payer name and date received — are treated as one, and only the first is
|
|
64
|
+
credited. If a customer really did send the same amount twice on the same day,
|
|
65
|
+
record the second with something that distinguishes it (the payer name exactly
|
|
66
|
+
as it appears on that transfer, for instance) so it is not collapsed into the
|
|
67
|
+
first.
|
|
68
|
+
|
|
61
69
|
- **Applying to a mismatched order** takes two deliberate steps. The first
|
|
62
70
|
click is refused with both amounts spelled out; only then does an explicit
|
|
63
71
|
"Yes — apply … anyway" control appear for that specific pairing, behind a
|
|
@@ -13,9 +13,18 @@
|
|
|
13
13
|
|
|
14
14
|
<dt class="col-4">Status</dt>
|
|
15
15
|
<dd class="col-8">
|
|
16
|
-
|
|
16
|
+
<%# Branch on status, never on the time-based `expired?` predicate. A
|
|
17
|
+
session is superseded (canceled) when the order was settled by another
|
|
18
|
+
method, and its expires_at is usually in the past -- reading the clock
|
|
19
|
+
first would badge a card-paid order as "Expired". Equally, a pending
|
|
20
|
+
session past expires_at that the sweeper has not reached yet is still
|
|
21
|
+
matchable by `.open`, so it is still awaiting a transfer, not expired. %>
|
|
22
|
+
<% case session.status %>
|
|
23
|
+
<% when 'completed' %>
|
|
17
24
|
<span class="badge bg-success">Paid</span>
|
|
18
|
-
<%
|
|
25
|
+
<% when 'canceled' %>
|
|
26
|
+
<span class="badge bg-secondary">Superseded</span>
|
|
27
|
+
<% when 'expired' %>
|
|
19
28
|
<span class="badge bg-secondary">Expired</span>
|
|
20
29
|
<% else %>
|
|
21
30
|
<span class="badge bg-warning text-dark">Awaiting transfer</span>
|