Account created on 19 January 2010, over 15 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States john.oltman

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!

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

This week. By 7/27 at the latest, probably earlier.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

Thanks @jonathanshaw, this is a nice improvement. Left a couple of comments for your consideration.

🇺🇸United States john.oltman

I reconfirmed the "Steps to Reproduce" on the latest 11.x branch.

🇺🇸United States john.oltman

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

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

Thanks, that makes more sense. I'll dig in and see what I can find.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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!

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

I followed your steps and it worked properly for me in a test system. What registration related permissions does your non-admin user have?

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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

🇺🇸United States john.oltman

verbiage

🇺🇸United States john.oltman

updates

🇺🇸United States john.oltman

heading

🇺🇸United States john.oltman

heading

🇺🇸United States john.oltman

headings

🇺🇸United States john.oltman

headings

🇺🇸United States john.oltman

captions

🇺🇸United States john.oltman

captions

🇺🇸United States john.oltman

image captions

🇺🇸United States john.oltman

update body

🇺🇸United States john.oltman

summary

🇺🇸United States john.oltman

spacing

🇺🇸United States john.oltman

summary

🇺🇸United States john.oltman

Related

🇺🇸United States john.oltman

Body

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

Description

🇺🇸United States john.oltman

Summary

🇺🇸United States john.oltman

Summary

🇺🇸United States john.oltman

Summary

🇺🇸United States john.oltman

Summary

🇺🇸United States john.oltman

Summary

🇺🇸United States john.oltman

Title

🇺🇸United States john.oltman

Title

🇺🇸United States john.oltman

Title

🇺🇸United States john.oltman

Weight

🇺🇸United States john.oltman

Title

🇺🇸United States john.oltman

Caps

🇺🇸United States john.oltman

Caps

🇺🇸United States john.oltman

Title

🇺🇸United States john.oltman

fix

🇺🇸United States john.oltman

delete

🇺🇸United States john.oltman

Title

🇺🇸United States john.oltman

Weight

🇺🇸United States john.oltman

Change parent guide

🇺🇸United States john.oltman

Title change

🇺🇸United States john.oltman

Title change

🇺🇸United States john.oltman

Fix typo

🇺🇸United States john.oltman

Nice! Thanks @benjifisher!

🇺🇸United States john.oltman

Good suggestions, I applied all of them. Feels lean and mean, see what you think.

🇺🇸United States john.oltman

This no longer occurs after upgrading to Drupal 11. Thanks for looking into this with me. Closing issue.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

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.

🇺🇸United States john.oltman

Going to try the steps above within the next week, will report back

🇺🇸United States john.oltman

Ah yes, that module appears to have some issues. Glad the wait list piece is working for you at any rate.

🇺🇸United States john.oltman

And I've been meaning to start my piece, hence the bump. Best laid plans... :)

🇺🇸United States john.oltman

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.

Production build 0.71.5 2024