The MR worked perfectly for me
john.oltman → created an issue.
john.oltman → created an issue.
Found a problem, back to needs work.
If you enable the registration_scheduled_actions submodule you can avoid custom code and schedule a reminder to go out the day before.
@jonathanshaw if you get a chance to review this, I updated the wakeup and sleep of a couple classes, PHPUnit 11 did not like some aspects of what was there before.
I committed your MR as it solves the problem and the approach I was thinking of is not viable (every registration in a given listing could have a different host entity). This will be in the next release, which is imminent. Thanks for the work!
Thanks for the post and the MR. I am able to reproduce this and should have a fix soon. I will end up closing your MR - it helps, but for sites allowing multiple spaces per registration it won't do what we need.
This week. By 7/27 at the latest, probably earlier.
Patch attached
john.oltman → created an issue.
Thanks @sagarsingh24, did you run database updates? If not, that would explain the one error that was not resolved. The type of format_plural should be boolean and not integer - and the database updates would assist with that.
Thanks @jonathanshaw, this is a nice improvement. Left a couple of comments for your consideration.
I reconfirmed the "Steps to Reproduce" on the latest 11.x branch.
Removed CMS blocker tag as a new release of the Events Registration recipe was done.
Merged 11.x in, back to Needs Review.
Here is the latest run of the Test-Only changes, showing the schema errors for the example view with aggregation enabled: https://git.drupalcode.org/issue/drupal-3263208/-/jobs/5885288
I ran into this recently and it cost me a debugging session. Let's get this fixed.
I used different text vs the proposed resolution, to be consistent with the verbiage for the related filterByFieldAccess method.
john.oltman → made their first commit to this issue’s fork.
john.oltman → created an issue.
john.oltman → created an issue.
I think you are likely running into this:
https://www.drupal.org/project/chosen/issues/3023506 →
Do you have a large number of users? If yes, the chosen module tries to load them all, so you could run out of memory. You could try increasing your PHP memory limit to see if that helps.
Thanks, that makes more sense. I'll dig in and see what I can find.
Thanks for the post. What is the use case? Is it your intent that people are registering for the paragraph, or the node/entity the paragraph is attached to.
Deleting a registration is like deleting a page - after you delete it, it no longer exists, and clicking on a link to it gives a 404, which is the correct behavior. Thus the entry in the logs is expected.
Regarding the memory error, your report is not that clear, but I think you are saying that clicking on the Register link for the host entity (to create a new registration) gives a memory error, but only after some other registration is deleted. However, you also implied that you attempted to click on a link to a registration after deleting it - is that when you received the memory error? Can you clarify, your use of the phrase "registration link" is ambiguous - are you referring to a link to a deleted registration, or the Register link for doing a new registration. If you received the error after clicking on the stale link to the deleted registration, that would point to an issue with your 404 handling, and nothing to do with the registration module.
Thanks for any testing you can do. Just a heads up I am going to add another commit so there is a permission allowing admins to ignore the Cancel by date. Since they may need to be able to cancel at any time for some sites. I'll add that within the next day or two.
Michael, the Cancel operation is added to the operations column of the registration listing - either the Manage Registrations listing for a host entity, or user registrations for a user, or the main listing of all registrations. It does not sound like you are bypassing the transition logic, unless you somehow have a custom operations column. That's ok - this should be a moot point soon with the new submodule I just committed.
Committed to 3.4.x and will be in the next release. To try it out now, download the dev version of the Registration module and follow the instructions in the README file in the modules/registration_cancel_by folder. I would only use the dev version on a test site.
No problem and good question. Answers:
[registration:entity:*] - That will get you fields on the host entity. For example, if the host entity is a node, and it has a field named "field_event_description", then [registration:entity:field_event_description] should print that.
[registration:host-entity:*] - That will get you "pseudo" fields relating to the host entity class, as follows:
[registration:host-entity:is-after-close]
[registration:host-entity:is-available]
[registration:host-entity:is-before-open]
[registration:host-entity:is-configured]
[registration:host-entity:registration-count]
[registration:host-entity:spaces-remaining]
[registration:host-entity:spaces-reserved]
This issue has some additional info: https://www.drupal.org/project/registration/issues/3378873 ✨ Implement full integration with ECA module Active
Hope that helps!
Side note: the ability to prevent cancel while registration is still open (e.g. 5 days before it closes) is a separate item that I'm working on as an enhancement. But based on your settings, the Cancel operation should disappear after close, using the current release. Let me know on the permissions and we'll go from there.
I followed your steps and it worked properly for me in a test system. What registration related permissions does your non-admin user have?
You should have a different option on the global admin page named "Require update access to registrations" - check that, clear cache, and see if the Cancel button goes away for your scenario. I am guessing the non-admin user already lost the Edit access based on your other change.
I will ensure the "cancel allowed" time period will be configurable.
I believe the prevention of status updates outside of the open and close dates set in the host entity settings is something that is already implemented, at least for non-admins (admins can always edit, and that needs to stay that way). Please check the global settings at /admin/structure/registration-settings, there is an option there.
Thanks for the post. This seems like a feature that many users of the module could benefit from. Will work this into the next release.
@sayyed raza haider your comment should have been posted in the issue queue for the Views Entity Form Field module, not here in Drupal core.
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.