Create a voucher custom entity

[pcambra]

We need a generic voucher entity that we can rely on for https://github.com/esmero/strawberryfield/issues/76. I think if we make it generic enough, it could be a contrib that we rely on.

Minimum features:

• [ ] Basic entity structure with admin UI
• [ ] Plugin based voucher seed generator (do we have a preference?). The entity should have methods to generate/regenerate a voucher.
• [ ] Voucher expiration time

[pcambra]

@DiegoPino I want to keep this one lean, the objective would be to create a "voucher" entity with a voucher field (initially a textfield but we could consider a custom field even. The seed to generate a voucher is something that intrigues me a bit, should it be something specific? I was thinking in either integrate something such as https://hashids.org/php/ or should we keep it simple by using https://www.php.net/manual/en/function.uniqid.php?

[DiegoPino]

@pcambra this makes sense.

To avoid too many update hooks afterwards, maybe discussing here/or from your side just state what other data you need in your entity? the file path? the user who owns it? a flag used not used or a "date" / expiration? And how that will play out with your expected future functionality? I'm very into data modeling (even that means little and a small one)

For the seed generator. Avoiding collision is so important. The entity by default will still have an UUID internally so that is unique enough (and good to keep), but a bad long string for end users to remember.

Wonder how well would this little fellow work for us? https://github.com/ai/nanoid and the PHP implementation https://github.com/hidehalo/nanoid-php

Because the facing hash is also a UI/UX concern right? @alliomeria thoughts?

[pcambra]

Fields I see useful for this entity:

On an hypothetical base voucher entity:

• id
• uuid
• owner
• creation date
• update date
• voucher (generated upon creation)
• expiration time (not required)

Archipelago could include fields to this:

• ADO reference.

I'm sure this entity doesn't need to be translatable. Maybe we could benefit from revision support.

We could include a default hashing mechanism but I'd like to keep it open (pluggable) in case we change our minds.

[DiegoPino]

@pcambra thanks this is good. Revisioning may be an overkill to begin with IMHO. Yes, let's keep hashing pluggable, won't affect the "resolving" back in any case because it will be always "string" based anyway (plus access check of course)

[DiegoPino]

Side note: @pcambra @alliomeria @giancarlobi could any of you verify (read docs, google it, make it up!) that this https://github.com/hidehalo/nanoid-php statement of a 21 long string has the same collision probability than UUID V4???? I that is right and we can trust the source (and whatever you come up) it really looks like a great alternative for the default of the pluggable option Like a really cool one

[pcambra]

@DiegoPino docs say:

"The main module uses URL-friendly symbols (A-Za-z0-9_-) and returns an ID with 21 characters (to have the same collisions probability as UUID v4)."

[pcambra]

Another alternative besides the hashids and the nanoids: https://github.com/mgrajcarek/uuid-shortener

[DiegoPino]

Yes! That is why i asked. What i mean is we can verify those words. If the algorithm has some wiki entry, some other supporting docs because its a bold statement

El El vie, 19 de mar. de 2021 a la(s) 13:30, Pedro @.***> escribió:

@DiegoPino https://github.com/DiegoPino docs say:

"The main module uses URL-friendly symbols (A-Za-z0-9_-) and returns an ID with 21 characters (to have the same collisions probability as UUID v4)."

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/esmero/strawberryfield/issues/166#issuecomment-802995563, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABU7ZZ2TLRX5DNHFWPHEG4LTEOC4JANCNFSM4ZOVOHVA .

-- Diego Pino Navarro Digital Repositories Developer Metropolitan New York Library Council (METRO)

[pcambra]

Recommendation to use gmp based on the uuid: https://titouangalopin.com/auto-increment-is-the-devil-using-uuids-in-symfony-and-doctrine/

[pcambra]

Pretty harsh criticism about nanoid in https://news.ycombinator.com/item?id=15225158

I found a recommendation there to ulid but that's js only, some ports:

https://github.com/kiwfy/ulid-php https://github.com/robinvdvleuten/php-ulid https://github.com/Lewiscowles1986/php-ulid

[DiegoPino]

@pcambra interesting discussion about Nanoid. Still it seems the discussion deviates to a less "polite" realm quickly. I get both parts. base64 encoding of an UUID v4 would give us a string we can revert, so you would really not need the extra "hash" but that is IF (same as in the discussion) you had not also the UUID which we get by "default" and good practice in Drupal. The arguments in favor of nano are that the uniqueness algorithm is good and that if you treat the hash as a string and not a transformed representation (that you want to decode back) is a nice one.

Feels like npm-users being npms...

How do you feel about base64 encoded UUID?

[pcambra]

Here's a pretty bold claim by nanoid https://zelark.github.io/nano-id-cc/ regarding how often an ID could repeat itself based on the amount of ids generated and the length.

If we go by encoding UUIDs on base64, we could go with hashids, which is base62. https://github.com/jenssegers/optimus is another option which is numeric only

[pcambra]

Initial version with nodeid support by default : https://github.com/pcambra/voucher