View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005778 | Composr | ecommerce | public | 2024-05-26 01:35 | 2024-08-04 23:25 |
| Reporter | Patrick Schmalstig | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0005778: Consider configurable point discounts | ||||
| Description | Consider the ability to configure how point discounts behave. Right now, point discounts cap at, and are forced to, 50%. Have a config option that defines the default discount threshold, and perhaps an option everywhere that prompts for a price and points to define available discount thresholds (comma-delimited). Pipe these via the hooks / automatic_discount_calculation . | ||||
| Additional Information | I had to eliminate the previous $consider_free behaviour because it was breaking the expected amount checks on transactions. So Composr now does not allow purchasing anything completely free with points unless the price is solely defined in points. It would be nice to let the user configure this globally and on a by-product basis for products that have both a price and a points. | ||||
| Tags | Roadmap: Over the horizon | ||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Automated message: This issue was created using the Report Issue Wizard on the Composr homesite. |
|
|
"I had to eliminate the previous $consider_free behaviour because it was breaking the expected amount checks on transactions" - can you say more about this, and link to a commit? |
|
|
https://gitlab.com/composr-foundation/composr/-/commit/b1e9d031797a5fc4014149f711e7b37209a5b1ac $consider_free was resulting in transaction checks made entirely by points to fail validation because the handler cannot convert between points and currency (either an error about unknown currency POINTS, or it improperly expected an amount of money on the transaction when it should have been 0). |
|
|
And that wouldn't have been fixable as a bug fix? I haven't look at that code in quite a while so I am rusty on it. |
|
|
I tried bug-fixing it but fixing it one way ended up breaking the system in another way. I couldn't find a fix that worked other than pulling it and implementing a skeleton to support custom discount ratios. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-07-23 17:08 | Patrick Schmalstig | Tag Attached: Roadmap: Over the horizon | |
| 2024-08-04 22:24 | Chris Graham | Note Added: 0009088 | |
| 2024-08-04 22:55 | Patrick Schmalstig | Note Added: 0009097 | |
| 2024-08-04 23:07 | Chris Graham | Note Added: 0009102 | |
| 2024-08-04 23:12 | Patrick Schmalstig | Note Added: 0009105 | |
| 2024-08-04 23:25 | Chris Graham | Assigned To | => Chris Graham |
| 2024-08-04 23:25 | Chris Graham | Status | non-assigned => assigned |
