In the end I have used the primary key for this and just used the member_id property for use on the site. In the instance the client hadn't used their membership number anywhere to prominent for this to be an issue.
Going forward I can see a legitimate business case for this though. Imagine a client where they had a few thousand members and had printed membership cards etc. already. Not being able to have an arbitrary membership number as part of the plugin would be a bit of a feature gap.
I'd foresee the following requirements:
- Read-only membership number for the user
- Membership number auto-creation based on a defined set of rules (may not always be numeric) defined in the settings
E.g. Length of "X" - Where X is an integer representing Length
Format of "AAXXXAXX" - Where A is alphabetic and X is a numeric, and the format is user-defined
Option of "Sequential" or "Random" for generating new membership numbers
Option to pad numeric membership numbers with leading zero's
Option of providing a "seed" i.e. the point where the membership numbers should begin from e.g. I have already used up to 4550, so my next member should be 4551
My thinking is that the primary key is really for database use, not for membership numbers. Hopefully some of the ideas above show where the differences lie.
I'll keep my fingers crossed that this gets considered! I kinda see it as a bit of a fundamental part of a membership system / platform.
Otherwise thanks for the awesome work, really impressed with the plugin :)
