Followup to #2730131: Add a commerce_number_pattern submodule for sequential (order/invoice) number generation.
{number} is a fake token, which means that it doesn't show up in the token browser, and the fact that it uses {} instead of [] is slightly confusing. Let's see if we can replace it with a real token. Current idea is to name it [commerce:sequential-number]. It's long, but descriptive. An alternative would be [commerce:number].
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | number-pattern-tokens.png | 263.83 KB | bojanz |
| #3 | 3080247-3-pattern-tokens.patch | 10.46 KB | bojanz |
Comments
Comment #2
tormi+1 for
[commerce:sequential-number].Comment #3
bojanz commentedThis patch replaces {number} with a [pattern:number] token.
It also introduces [pattern:day], [pattern:month] and [pattern:year] for the most common date tokens (to have consistency in the prefix used).
We also have a [pattern:date:?] which works the same as [current-date:custom:?], and is meant to be used for more exotic date use cases.
Global token types have been hidden, so that the user doesn't see the duplicate [current-date] tokens.
The [pattern] tokens are not global, so they won't show up in other UIs.
If any module defines a "Pattern" entity type, there will be a conflict, but I'm prepared to take that risk for better UX.
Our initial attempt was [current-pattern], but that's longer and potentially confusing. I like having the token prefix match the name of the field where it's used ("Pattern").
Comment #5
bojanz commentedCommitted.