Allow admins to change host entity for existing registration

You can use Inline Entity Form for forms https://www.drupal.org/project/inline_entity_form

Hi, I would really appreciate this feature.

I have working code for this, as a new submodule of registration, I will open an MR here in the next few weeks.

@jonathanshaw: Great, thanks you!

So, how is it, does it work in v. 3.1.1?

Sorry this has been slow, but it really is coming. Should be doing the final touches very soon.

I think it's worth considering #3419239: Establish host variations as an architectural concept as it makes this easier.

Chiming in - in my view, the candidate list for the new host entity should be any host entity matching the registration type of the registration that wants to change its host - it does not need to be limited to just those hosts for the same "event". For example, in a Commerce context, I do not think it needs to be limited to only those product variations that are "siblings" (attached to the same product as the original host entity). In the real world, people often want to change from one "event" to another - for example, I have an appointment for a class, and want to switch classes but keep the other registration data intact.

Created a new MR with a new submodule to change the host entity.

Thanks Victor for your contribution! I tried this out on a local test system - from what I can tell, in order to engage your module, you have to write an event subscriber in a custom module to identify which host entities can be used as the new host - is that accurate? I can give more feedback but wanted to start with that question. (I like the idea of using an event for this BTW.)

In order to engage your module, you have to write an event subscriber in a custom module to identify which host entities can be used as the new host - is that accurate?

Yes. I had been concerned that showing all hosts would be a bad choice in almost all use cases, although now that I think of it I realise that showing all hosts open for registration currently could be alright for staff in many use cases, although again unlikely to be adequate for users in most use cases.

I plan to provide an event subscriber allowing to change to other variations of the same product for commerce_registration, which is the main use case I've been thinking of.

Re #12 I definitely think we should *allow* changing host without hardcoded restrictions. But I'm expecting that every site would need to make it's own decisions about which changes to allow based on it's business logic - I don't see how we can really help with this. Hence the "highly flexible but completely opt in and code based" approach of the MR.

Thanks jonathan, didn't realize you and Viktor are working together, nice. Some great work here. Issues with the current MR:

* tests are failing and phpstan is reporting a warning
* after enabling the module I lost my ability to do a regular registration edit - needs to be some way to trigger the change host action - perhaps through a "Change Host" action button at the bottom of the View Registration page (see registration_workflow_preprocess_registration for example) or through a new "Change Host" tab for the registration, or both. The route should have a custom access checker that disables the route for the given registration unless there are at least 2 possible hosts. If you don't provide a custom event subscriber to provide possible hosts, then the admin UI experience should be as though the module were not enabled.
* The paths and verbiage should be more clear about what is happening. "Select registration type" (/type) should probably be "Select new host" (/change-host) and "Update registration" could be "Confirm and save new host" (/change-host/confirm) or something like that. Also, if the registration type isn't changing, then there is no need to launch step 2 for the field updates and it could simply be a confirmation page "You are about to change the host from X to Y" with Confirm and Cancel buttons.
* The selection interface for the new host is really neat - but it needs to exclude any possible host that is not configured for registration - and if too many possible hosts are returned, maybe it needs to have a pager (i could accept without a pager for now).

Setting this issue to "Needs work". If you need assistance with the legwork on the above, let me know.

Also - probably need a separate permission for changing host. Maybe "administer registration" gets access automatically, and then a new permission that can be added to roles for non-admins. On some sites, I could see a use case where some people can edit registrations and others can change the host but not edit.

Sorry for the delay here, I will get Victor to make these fixes.

The paths and verbiage should be more clear about what is happening. "Select registration type" (/type) should probably be "Select new host" (/change-host) and "Update registration" could be "Confirm and save new host" (/change-host/confirm) or something like that.

This makes "host" a user-facing concept. But its meaning is completely opaque to a site's user, certainly to a non-staff user.
I think hosts is ok for the path - people aren't surprised by weird urls.

Ideally for on-page text maybe we should use the label of the host bundle. But in practice this seems tricky as there could be multiple valid host entity bundles or even entity types. I suppose we could use the bundle label if all available hosts are from the same bundle, the entity type label if they're all of the same type but different bundles, or "host" if there are multiple types involved? That's probably the best UX.

The selection interface for the new host is really neat - but it needs to exclude any possible host that is not configured for registration

I've asked Victor to fix this in PossibleHostEntity::access(). This way event subscribers can return hosts to be listed, but displayed as unavailable. I'm imaging that some sites might sometimes want to list a certain option without making it available (e.g. marking it sold out) rather than simply hide the option altogether. template_preprocess_registration_change_host_list() only converts a list item to a link if its access is allowed.

Updated the MR.

Awesome, looking forward to trying this out again. Will review within the next few days.

This is pretty ready for review, although I've asked Victor to tweak the hook_entity_access a bit.

Yeah, I see what you mean - the entity access hook is not setting the cache dependencies. The function "node_node_access" in core shows roughly what has to be done - caching either per user (for "own") or per permissions, and adding cache dependencies on both the registration and the existing host entity for the registration. Also, it should return forbidden unless the host can actually be changed (> 1 possible host), even if the user would otherwise have access. No sense in showing the Change Host tab for no reason. In my view the change host manager should actually remove the existing host if it's in the list returned from the event - that way you can just see if the possible hosts is empty in the access check.

Everything else is looking really good. Setting to needs work for these last tweaks. Thanks!

Also, it should return forbidden unless the host can actually be changed (> 1 possible host), even if the user would otherwise have access.

I believe Neutral is equivalent to Forbidden for route access, but Neutral would allow RegistrationAccessControlHandler to override and grant access if the user has administer registrations permissions, so I think that will be the better approach to DRY.

quick update: currently, I’m busy with some other things. so, will continue working on the issue in one or two weeks

thanks for understanding

No problem, thanks for the update Viktor