search

CORE-POS / IS4C

Cooperative Operational Retail Environment
http://www.core-pos.com
GNU General Public License v2.0
63 stars 44 forks source link

Flags for customer records #1208

Open flathat opened 9 months ago

flathat commented 9 months ago

I'm looking at setting up a lane-side feature that requires a per-customer flag, something the member (or even Household Member) would opt in to. As an alternative to adding a field to Custdata I wonder if one of its fields that is not currently being used could be officially re-purposed for bit-level flags the way products.numflag is used? The best candidate might be Custdata.NumberOfChecks, a SMALLINT that only seems to be used in cron/members.sync.with.CiviCRM.php. Some of the bits could be reserved for official CORE flags and the others left for installation-specific uses.

gohanman commented 9 months ago

That seems fine insofar as the world is unlikely to see a resurgence in check-writing that makes that field useful for its original purpose. Design-wise, I'm not sure products.numflag turned out to be a good design. It's relatively annoying to manage compared to other fields. Unless it's something super esoteric I think it'd be worth considering just adding a column.

flathat commented 9 months ago

What I like about the numflag approach, especially for locally-defined flags, is that:

My current project is a plugin to automatically do RoundUp without asking the member every time. Each member would have to opt in. This has been requested by some members. If it works out I'd probably want to make the plugin available to the upstream repo. It doesn't seem "super esoteric" at this point but it might not work out, in which case the new field would be deadwood, at least at this co-op. It would also be deadwood anywhere the plugin wasn't enabled, probably at most installations. I have another plugin, that uses a products flag. One of its parameters is the Nth flag (as established in ItemFlags.php) so that that value could be different at another co-op; and the flag doesn't appear at all if the plugin isn't enabled.

Support for managing customer flags would have to be added. Could be plugins (which I could write):

I didn't see a field in the new customers scheme, the Customers/CustomerAcconuts tables, that could be repurposed for this, so that support would be further down the road.

gohanman commented 9 months ago

I think the round up thing has become common enough that having a dedicated column could make sense, but I see your broader point about having a sort of free-form field that can be shared and/or used differently in different places. I do think it might make sense to add a column named Flags (or rename NumberOfChecks). It's not exactly friendly to new developers to have a name that's really misleading about what the field is for.

lgedgar commented 9 months ago

FWIW my sense is that a generic Flags (int) field might be useful, but if round-up is somewhat common, should just give it a dedicated flag (bool) column of its own regardless.

flathat commented 9 months ago

Flags, a new field, as a full INT is my preference. UNSIGNED if it matters.

Might be good to restrict to the first n bits for local flags, the upper for "system". I thought this was done for products.numflag but can't find where it is specified or enforced unless it is in the limit of the first 30 bits of a 32-bit integer in $ITEM/ItemFlags.php. Help there says: "Flags can add new settings that are not built-in such as gluten-free or organic."
but I'm not clear what is "built-in".

If you'd rather re-purpose NumberOfChecks the only documented use of it, in my cron/members.sync.with.CiviCRM.php, is basically as a flag and I could change that to look at NumberOfChecks as a set of flags.

Basic "RoundUp" doesn't need a flag, needs no enablement; see $LANE/parser/parse/DonationKey.php. "AutoRoundUp" is what I'm working on supporting with, hopefully, custdata.Flags.

gohanman commented 9 months ago

A new Flags field would also be my preference. I don't think it matters on a bits level whether it's signed or unsigned.

As far as what's built-in, I think it would be this: https://github.com/CORE-POS/IS4C/blob/master/fannie/install/sample_data/prodFlags.csv

flathat commented 9 months ago

Great! Shall I do a merge request or will you?

Do you want to reserve some of the bits?

UnfiUploadPage ->getFlags() assumes the 17th and 18th bits are organic and GF, respectively.

gohanman commented 9 months ago

Merge request is yours.

It's probably reasonable to reserve some in case there are any we want to make available out of the box as standard options (maybe including this round up one?). Doing the same top half would be consistent, but probably doesn't need to be decided right now. I expect it'll be a while before any store is actually using double-digit custom flags.