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.
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.