- Issue created by @jonathanshaw
- πΊπΈUnited States john.oltman
I believe we are going to end up keeping "set and forget", but I've changed the status from Closed to Postponed, in light of my reopening of the cache expiry issue. Please note that "set and forget" is also used to initially open registration, not just disable on close.
- π¬π§United Kingdom jonathanshaw Stroud, UK
I get the idea of a setting that controls whether or not register links/tabs still show even when they are no longer truly registerable.
The "keep showing a register link but take people a page that lists reasons why they can't" approach is not a bad idea, although for many sites registering is such an important call-to-action that relying on a tab for it makes no sense and something like RegistrationLinkFormatter is a better approach, in which case π Show causes with registration link Active opens up a better solution to informing people about why they can't register.
Nonetheless, I can see a case for keeping a setting here. What I'm less sure about is keeping the mechanic that powers the existing setting. But (ab)using the status setting to handle this scenario, we make it harder to know what is means when a host is disabled as we found in π Decide whether 'status' and 'close' validation errors should be shown at same time Active .
It is now technically possible for us to stop relying on the cron/status mechanism and instead use HostEntity::isAvailableForRegistration() in the register route access check, but only if set_and_forget is enabled. This would have the advantage of also removing the register link if the host was full or you had already registered, which is probably what someone also wants if they want to hide register when an host is closed or not yet open.
BC is a headache here. One solution would be to add a new setting and deprecate the old setting with a hook_requirements() block that prevented upgrading if the old setting was enabled.
- πΊπΈUnited States john.oltman
Set and forget is going to be around for quite some time, and possibly always. We can reopen if a new rationale presents itself. The original rationale is no longer present since isAvailableForRegistration cannot be called from the access check for performance reasons.
- πΊπΈUnited States john.oltman
Reopened per π Add a new HostEntity method isOpenForRegistration Active .
We'll see if we can get rid of it. If yes, then this statement of mine didn't age well, LOL.
Set and forget is going to be around for quite some time, and possibly always.
- Merge request !127#3497731: Deprecate the "set and forget" setting β (Merged) created by john.oltman
- πΊπΈUnited States john.oltman
john.oltman β changed the visibility of the branch 3497731-remove-setandforget to hidden.
-
john.oltman β
committed 3821c224 on 3.3.x
#3497731: Deprecate the "set and forget" setting
-
john.oltman β
committed 3821c224 on 3.3.x
- πΊπΈUnited States john.oltman
The code to remove the feature entirely is in a hidden branch, but I realized after starting it that it needs to be deprecated first. So in registration:4.0.0 we can use that code.
- Merge request !129#3497731: Provide replacement for "set and forget" β (Merged) created by john.oltman
-
john.oltman β
committed 78f00fe7 on 3.3.x
#3497731: Provide alternative for "set and forget"
-
john.oltman β
committed 78f00fe7 on 3.3.x
-
john.oltman β
authored b5bb08cd on 3.4.x
#3497731: Adjust deprecation text
-
john.oltman β
authored b5bb08cd on 3.4.x
Automatically closed - issue fixed for 2 weeks with no activity.