[dreamwidth/dreamwidth] bfe982: shop til you drop (#3007)

[github]

Branch: refs/heads/main Home: https://github.com/dreamwidth/dreamwidth Commit: bfe9820342c34fbda5658d20ae0f22bb4c631e8f https://github.com/dreamwidth/dreamwidth/commit/bfe9820342c34fbda5658d20ae0f22bb4c631e8f Author: Jen kareila@dreamwidth.org Date: 2022-11-09 (Wed, 09 Nov 2022)

Changed paths: M bin/upgrading/en.dat M cgi-bin/DW/Controller.pm M cgi-bin/DW/Controller/Shop.pm M cgi-bin/DW/Shop/Engine/CheckMoneyOrder.pm M cgi-bin/LJ/Widget/ShopCart.pm M etc/config-local.pl.example M etc/config.pl.example M htdocs/shop/renames.bml M views/shop/index.tt M views/shop/index.tt.text

Log Message:

---

shop til you drop (#3007)

• site configuration misbehavior: turning off shop components

It is easily possible to disable the individual sections of the shop that sell icons, points, and rename tokens, but the storefront was not designed to gracefully handle that configuration.

In the case of points or icons, the cart would throw a generic error when submitting the form. In the case of rename tokens, the "Add To Order" button would just silently fail.

Although it is unlikely DW will ever disable these shop items, let's update the code to be better behaved on general principle.

(Unavailable account levels are already handled in a reasonable manner.)

This also adds the missing 'icons' key to the example %LJ::SHOP hash.

• site configuration misbehavior: turning off the shop entirely

Visiting any shop page with the 'payments' config option turned off results in a completely blank page and an error in the logs that says: Argument "The shop is currently disabled." isn't numeric.

Looks like this happened because of a misunderstanding about the intended return value of DW::Controller::controller. The relevant code comment says to return "error text" if there was an error, but the error message can't be just a string, it has to be a server response. Perhaps the behavior was later updated in order to allow other possible responses such as redirects.

At any rate, the fix is to use error_ml here. The subsequent sysban check obviously has the same problem, so this fixes that as well.

• [#2974] enforce minimum amount for check/money order payments

Defines a new config parameter $LJ::SHOP_CMO_MINIMUM. If set to a value greater than zero, that value will be the minimum "cash" value required to accept check/money order payments.

Fixes #2974.

• [#2328] print the currency to 2 decimal places in receipt email

As reported some time ago, the "Amount Due" was being shown as e.g. $20.2 instead of $20.20. Future emails will print the amount with the standard number of decimal places.

Fixes #2328.

• new 'payments_cmo' option for LJ::is_enabled

As mentioned in #2974, it's possible that we may need to entirely disable paying by check or money order in the future due to increasing costs. This adds a 'payments_cmo' test to LJ::is_enabled that will make the switch easy to flip if that day comes.

[dreamwidth/dreamwidth] afa02c: final (for now) round of tellafriend fixes (#3005)

[github]

Branch: refs/heads/main Home: https://github.com/dreamwidth/dreamwidth Commit: afa02c2b13dd3a5bb7205d4c985f9b159b6845cd https://github.com/dreamwidth/dreamwidth/commit/afa02c2b13dd3a5bb7205d4c985f9b159b6845cd Author: Jen kareila@dreamwidth.org Date: 2022-11-09 (Wed, 09 Nov 2022)

Changed paths: M cgi-bin/DW/Controller/Tools.pm M views/tools/tellafriend.tt M views/tools/tellafriend.tt.text

Log Message:

---

final (for now) round of tellafriend fixes (#3005)

• hush uninitialized value warnings related to empty message body

• send from dw_null, reply-to user's own email

Currently, the header of the generated email looks like:

From: "[[username]] via [[sitename]]" <[[user's email]]>

This updates it to come from $LJ::BOGUS_EMAIL, with the user's email as a reply-to:

From: "[[username]] via [[sitename]]" <[[dw_null@site]]> Reply-To: "[[username]]" <[[user's email]]>

This change also makes it more likely that the message will actually be delivered by SES.

Fixes #1866.

• fix problem with $default_formdata being ignored

Since $r->post_args is never empty (it's a Hash::MultiValue object), let's use the value of $r->did_post instead.

• update the form display to better reflect the actual email header

also displays the message subject, which was hidden before