Good call - you are correct - I can determine which server it belongs to from the url. So the update hook can always do the move. Scratch what I said about keeping the global setting. Thanks @pavlosdan!
For a new site the global setting would be hidden.
Yes, the challenge there is for a site with multiple Drupal search stax servers, which server should the update hook move the global settings into. Maybe I keep the global setting and simply add the per-server config. And the global is only used as a fallback if a suggest URL is not defined in the server yet.
I created https://www.drupal.org/project/searchstax/issues/3551333 ✨ Move auto suggest URL from global settings to server config Active and plan to work on that over the next few weeks unless someone beats me to it.
There is only one bug, not two. The bug in #3514883: Assertion fails when using external stream wrappers (e.g. s3fs) in PublicFileIntegration → was not fixed properly, creating a regression covered by this issue. We need a solution to that bug that does not cause a regression, at which point both issues (the original bug issue, and this regression issue) will be solved.
Yes, applying the patch simply reverts the change that caused the regression, which is why I did not originally mark this issue as Ready for Review, @ludo.r did a few days ago. I agree that Needs Work is the correct status at this point. The next step is for someone to develop a fix for the original bug that does not cause a major regression. That fix would ideally be an MR attached to this issue.
Thanks for that info, I'll see what it takes to make it work using the Paragraph as the host entity.
It works this way on purpose so if you re-activate, you get your old settings back. There is nothing wrong with have settings data stick around. That said, adding an option so it does go away isn't a bad idea either. Changing to Feature Request.
Thanks for taking a look @smustgrave. No, that text is not necessary and superfluous once the MR is applied. The new text was chosen specifically to be similar to the text for the similar filterByFieldAccess method that follows. This way both "filter" methods have similar doc, as they should.
john.oltman → created an issue. See original summary → .
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.