Version 1.7.3 is a two line hotfix, the kind of release that is usually a changelog entry and nothing more. This one had a second failure folded inside it that is worth naming: the activity log reported a change that had not happened.
The failure
If your site runs a persistent object cache, meaning Redis, Memcached, or a drop-in your host installed for you, then turning off read-only mode or the high-risk WooCommerce lock could fail to take effect. The plugin deleted the option row that stores the setting. The cache went on serving the old value anyway. So the setting you had just changed was still in force, while the Settings screen and the activity log both reported the change as done.
The two switches failed in opposite directions
Read-only mode failed safe. Turning it on blocks every write, so if turning it off did not take, writes stayed blocked. Your site was more locked down than you asked for, which is frustrating without being dangerous.
The high-risk switch failed the other way. Nine WooCommerce abilities that move money or grant authority stay locked until you switch on a separate control in Settings, and turning that control back off is how you re-lock them. If that did not take, those nine stayed unlocked after you believed you had closed them.
Why the log entry is the worse half
Either way, the activity log recorded the switch as turned off.
A governance switch that fails is findable, because sooner or later the behavior stops matching the setting and you go looking. A log that records what you asked for instead of what happened removes the place you would have gone looking. We have written before about what the audit log actually stores and why it records denied attempts next to allowed ones. This did not meet that standard: the entry described the request rather than the result.
The fix
Both switches now clear their own cache entries, read the stored value back to confirm it took, and report an error naming the cache when it did not, rather than writing a success row. Reset to defaults and delete on uninstall got the same cache-safe delete, so a stale cache cannot bring a setting back after a reset.
No screen changed shape. A new error message appears on the Settings tab only in the case where a switch genuinely fails to persist.
Whether you need it
Only if your site has a persistent object cache. Plenty of shared hosting has none, and on those sites none of this ever applied. If you run Redis or Memcached, or you are not sure whether your host installed a drop-in of its own, take the update.
Nothing else moved. The catalog is still 153 abilities, with nothing added, renamed, or shifted to a different permission, and read-only mode and the high-risk lock behave the way they always did. The difference is that on a site with an object cache they now do it reliably.