Created outline: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → . The pages are all empty for now - my thought is many will eventually be a screenshot and explanation.
@jonathanshaw your Permissions page is in the Registration overview section. There is a separate Concepts page now, some of what you have on your page could be moved there. There is also a Configure permissions page in the site builders section, my thinking there is it would be a screenshot and example with some description, with a link to your existing page for those wanting more information.
Nice! Thanks @benjifisher!
Good suggestions, I applied all of them. Feels lean and mean, see what you think.
This no longer occurs after upgrading to Drupal 11. Thanks for looking into this with me. Closing issue.
There is also a case to be made that I should have deprecated the two formatter classes I removed but kept them there as null classes - meaning they simply extend the core registration formatters with no overrides - so as to avoid the issue you are running into. Let's see how your rewrite goes. For now I will reopen the issue in case I decide to add the classes back.
Ah, I was afraid of that. I wonder if you can change the extending class to inherit from the link formatter in registration core. If you need any assistance please feel free to ping me directly through my Drupal.org contact form.
This worked out nicely. I added the test as a Kernel test since a browser is not needed and kernel use fewer GitLab resources and run much faster than functional. I named the test class generically as RowTest in case we or future maintainers want to add more tests for other methods of the class. For now the existing test validates the destination methods with a focus on the new methods. Back to ready for review.
The class is no longer needed due to enhancements in the core registration module. Make sure you updated that module in tandem. I kept the test file as it exercises the link formatter in ways that only commerce registration can, so it is worth keeping. I do see that I need to update the comment in that test file, which I will take care of.
As far as the error goes, clear cache and it should go away. If that doesn't do it, I'll need the name of the include file or a full trace, you should be able to get that from the logs. Tests are passing so it is unlikely anything other than the comment in the test file needs changing, but we will see.
Thank you, I'd be happy to create the functional test you describe. And your understanding is perfect. I'll hop on this and get something posted within the next week.
Going to try the steps above within the next week, will report back
When will this be released?
Ah yes, that module appears to have some issues. Glad the wait list piece is working for you at any rate.
And I've been meaning to start my piece, hence the bump. Best laid plans... :)
The standard registration admin edit form doesn't do that. Are you using some sort of inline editor from the listing? There is no code in the registration module that resets the created date, so it likely is coming from some other module.
Thanks for your review, this is ready for another look.
I think we should not implement the two convenience methods.
Good points, I removed those two methods.
This is one more line, but it is fewer characters.
That is a nice optimization, I applied your suggestion to the MR.
On second thought, I do not think we need to add hasEmptyDestinationProperty().
I kept this method in for these reasons:
* It causes no harm
* It provides symmetry with the destination "has" method, and thus contributes to the ability to understand the Row class
* It provides information hiding of the internal implementation, which is an accepted principal of good API design
I can take it out if required, but would prefer to keep it if you are amenable on this point.
john.oltman → created an issue.
A custom entity type without a label will trigger the error mentioned by @ghost-of-drupal-past when using a DraggableListBuilder and when saving the entity using EntityForm. I'll open a separate issue, but the solution might be a rollback of this change.
john.oltman → created an issue.
john.oltman → created an issue.
Committed to dev branch and will be in the next release which should be in a week. To use this feature, install the
Weight module →
and then add a weight field to your registration type, make sure it has a Default value of 0. Configure the form display for your registration type so the Weight field is shown on the "default" display that admins use, but is hidden on the "register" form display that registration forms use (create the "register" form display if needed, make sure the machine name is register). Then edit the registration type and change the Autofill Sort Field setting to use the your new weight field instead of Registration ID. When your site admins want to prioritize a given wait listed registration for autofill, they would set the weight field to -10 for example, and it will autofill first. If you prefer the admins use a positive number so it is more like a Priority, simply flip the AutoFill Sort Order on the registration type from ASC to DESC.
Code snippet in an event subscriber:
public function onPreRowSave(MigratePreRowSaveEvent $event): void {
$row = $event->getRow();
if ($field_name = $this->complexBusinessLogicThatDeterminesWhichFieldNotToAlter($row)) {
if ($row->hasDestinationOrEmptyProperty($field_name)) {
$row->removeDestinationOrEmptyProperty($field_name);
}
}
}
public static function getSubscribedEvents(): array {
return [
MigrateEvents::PRE_ROW_SAVE => ['onPreRowSave'],
];
}
Yes, typically an update migration. I have a client with a business rule that states that under certain circumstances, data in an important field should not be altered or removed by a migration import, even if it otherwise would be. This is impossible without patching the Row class. Simply put, the class has two protected variables that work in tandem, destination properties and empty properties. The destination has set, get and remove. The empty only has set and get. It needs remove, just like its sibling. Call it a feature request if you will, but it seems to be an oversight.
Regarding `hasDestinationOrEmptyProperty` and `removeDestinationOrEmptyProperty`, those are convenience methods - strictly speaking they are not needed, but are very useful when trying to implement the "prevent alteration of field in any way" use case. We might as well add them while we are in there.
You would probably have to override the field formatter in a custom module. Or try out String Overrides:
https://www.drupal.org/project/stringoverrides →
Unfortunately it does not have a D11 release yet.
Was thinking along the same lines.
This could be a common need - the ability to override what gets autofilled next. Let me mull this over and see if I can get something into the next release of the module, due out in mid-May.
Ah, Registration Date is a reasonable choice. Just curious - are you sure you want to enable Autofill? If you disable Autofill, you can hand select and edit the Registration you want to take the place of the deleted/canceled registration and set its state to Complete, avoiding this issue entirely. I guess the downside would be someone could do a new registration before you get a chance to fill it manually, but editing the registration date in advance of a cancellation is manual too.
Fields in Drupal provide the ability to set a default value. If you edit your Registration field (presumably attached to a Content Type), you should be able to enable Autofill by default and set the default state.
Currently the oldest non-complete registration, as determined by the lowest registration ID, is selected. If you have the ability to create a custom module you can change that in a few different ways. What logic do you want to use instead?
If you have autofill enabled, there is a new field on the per-host-entity registration settings page named Autofill state. You can change that from Pending to Complete.
john.oltman → created an issue.
john.oltman → changed the visibility of the branch 3520065-migrate-row-remove-empty to hidden.
john.oltman → created an issue.
Thanks for letting me know things are working now! Glad it worked out. Email delivery can be a little tricky at times.
In the latest version of the module 3.4.2 the field formatters have options for showing "reason text" if registration is not available. So you shouldn't require a special template to get some basic text output. See if that helps.
john.oltman → created an issue.
john.oltman → created an issue.
The confirmations are separate. So disabling registration_confirmation only disables the "registration completed" email. Disabling registration_waitlist disables the "you were put on the waitlist" email. They are intentionally completely separate, and should remain separate.
Moving all confirmation code to registration_confirmation module would mean...
You aren't moving anything. You are adding new functionality (admin notification) to both submodules. The functionality is similar in both, and if you want to add some code to the core module in Notify/RegistrationMailer.php that the new functionality can share, that is fine. But don't move any code around. Just add similar code to both submodules.
What you are proposing would create dependencies between the confirmation and waitlist submodules that we don't want, forcing users to always enable both. We can't do that, they have to be separate, waitlist functionality must go completely in the waitlist submodule and confirmation similarly completely in its submodule. Regarding sharing - they both already share an action - I'm not sure how much more can be shared. If you want to add another method to Notify/RegistrationMailer.php (already exists) that would serve both modules, that can work. Thanks for looking into this!
john.oltman → created an issue.
Added new filters for:
* Host entity spaces remaining
* Host entity spaces reserved
* Host entity registration count
Committed to dev branch and will be in the next release.
john.oltman → created an issue.
Thanks @wattdesigns, the new submodule concept is out. What is on the table is the CC you suggest - and @milos would also like the option to have a different message to an admin. If/when he submits this work, your CC will be in there, so you'll be covered. The extra message field does not complicate things so much that it puts this beyond reach.
Looked into those modules and they are not suitable in my view - the integration paths are difficult and each has issues. For example sm has a very small install base, and message requires too many other modules as dependencies. Workbench works with content and adapting for registration would be a major effort. In short I think the best way forward for this particular need is either in a custom module, or adding to the confirmation and waitlist submodules of registration. I am comfortable with any decision you make - custom is probably slightly easier so I understand if you go that path. I promise if you do decide to take on the changes to confirmation and waitlist that I will review quickly and get your code merged as soon as practical after you submit an MR. Thanks @milos.
Perhaps there should be a checkbox (by default checked), allowing to send either a copy of the user confirmation message or a separate message?
I agree with this.
Thanks for posting this issue @daniel, I committed the fix to dev branch and it will be in the next release around May 4. You will need to first assign a default value to the field using the standard widget (i.e. assign a Registration Type to the field). After saving the default value, you can switch to using the read only widget, and you should select Registration Type as the formatter for the read only widget settings. If you don't do it this way, the registration field is essentially hidden on the node form, which defeats the purpose of using the read only widget vs just disabling the field on the form.
Agree that an admin needs a different confirmation vs. the registrant. Also agree this is getting too big and unwieldy - the modules you mentioned look interesting. Let me look into those and see if maybe an integration submodule, rather than more code in registration_confirmation, is a better approach. I'll research and get back on this issue within a day or two.
This issue is for notifying admins when the Email Registrants form is used (via the Manage Registrations area) - not on registration confirmation.
Thanks @milos - if you are going to code it, should it be incorporated as an addition to the existing registration_confirmation submodule? That would make more sense to me than a new submodule. Basically it would add an admin email field to the existing form, above the subject field, perhaps with a description like "Send a copy of the confirmation to this email address". Maybe there would be a checkbox for "Send a copy to the author of the host entity" as well.
Thanks @milos, let's keep things in this issue - this can pop to the top of my to-do list. I'll get the filter etc into the next release, I'll use this issue. And yes - fresh documentation is needed for all features of the module - that is coming over the next few months.