- Issue created by @jonathanshaw
- πΊπΈUnited States john.oltman
Thanks for this excellent post @jonathanshaw. Abstracting the host entity further could also help with a number of other feature requests besides the "change host entity" request:
* https://www.drupal.org/project/registration/issues/2587903 β¨ Option to make a registration selection Active
* https://www.drupal.org/project/registration/issues/2634340 β¨ Support multiple capacities by type Active
* https://www.drupal.org/project/commerce_registration/issues/3415425 π¬ Multi-Level Pricing? ActiveIn all three of those requests, there is a need to have the host entity context be different, and at a "grouping" level (i.e. product in a Commerce install), vs. where the registration field is attached, at least for some checks like capacity. You are definitely onto something here. One issue is the context will be totally variable per site - for many, the "event" will be at the variation level and not the product - for others (sounds like your site) the context is at the product level. Certainly in the scenarios in those three feature requests, some host entity checks need to be at the grouping level - maybe all - not sure yet. Going to ponder this further.
- π¬π§United Kingdom jonathanshaw Stroud, UK
My basic thought on the 3 issues you reference is: the challenges we face here are very similar to those commerce faces with products and where they have huge real world experience; leading them to the products, variations, attributes architecture. I'm particularly thinking of the way variations can be auto-generated from combinations of attributes, being the atomic unit to define the customer choice although not always customer-facing.
Maybe we need the same basic setup:
- the atomic host variation
- the grouping that holds a set of atomic hosts
- a range of services to get availability etc that can be decorated/overridden like commerce's price checker etc services, because we know our simple 2 level architecture won't suit every use case. - π¬π§United Kingdom jonathanshaw Stroud, UK
I realised there's an important distinction between shopping and registering. A person can buy as many different things as they like, and as many of each thing; but a person can only be in one place at a time. Thus there are hosts a user should not be able to register for if they have already registered for another 'host' within the same 'scope'.
This suggests we do have a clear need and meaning for a concept of 'scope' that is higher-level than host. Different sites might attach different meanings to the idea of scope just as they do to host, but the one we insist on is that there can't be multiple registrations of the same user within a single scope.