Open flathat opened 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.
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):
products
' $ITEM/ItemFlags.php
to assign local meanings.products
' $ITEM/modules/ItemFlagsModule.php
to turn on/off per member.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.
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.
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.
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
.
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
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.
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.
Version of CORE? Current
Issue with Office, Lane, or both? Lane, mostly.
Is this [mostly] a bug report, feature request, or question? Feature request
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 wayproducts.numflag
is used? The best candidate might beCustdata.NumberOfChecks
, aSMALLINT
that only seems to be used incron/members.sync.with.CiviCRM.php
. Some of the bits could be reserved for official CORE flags and the others left for installation-specific uses.