Roadmap for 3.0.0 release

@freelock, thank you very much for your hard work on this module.

Is the work still going on for the new maintainer team?
I'm asking as 3.0.0-alpha1 released 14 April 2020 still says "Requires Drupal: ^8.8.4" - not Drupal 9 and has 11 Test errors. Could you give us an update? Thank you :)

I also wonder about this: If the D9 compatibility is done, then it would be nice to be able to use the code in Drupal 9 :). The current "Requires Drupal: ^8.8.4" means I cannot enable the module in my Drupal 9.2.5 install.

Great work with this!

Thank you @freelock! :) Looking very much forward to that!
You're right! I just checked the .info file from 3.x dev and it contains
core_version_requirement: ^8.8.4 || ^9.0! :)

Sooner or later a new 3.0-alpha2 would be nice to make Drupal 9 compatibility transparent in the download section, which is a bit confusing, see #8.

Hi @freelock any news? Are you still working on this? I saw MegaChriz also being involved?

This project is still very relevant to Drupal I guess, could you update the plan?

Issues I from GitHub also never were resolved, but are still relevant:
https://github.com/dpi/rng/issues
https://github.com/dpi/courier/issues

Is there any plan to check them?

Seems the project is dead (once again). Sad story.

@Anybody
Yes, the client had only given me so much time to work on this project. I did what I could in that timeframe. Trying to fix the registration UI was one step too far, especially since for my client I was already using a custom built UI.

@MegaChriz, thank you for your reply! What's your opinion about the state of this module after that?

Unassigning @freelock as he seems inactive.

@Anybody
The registration UI looks broken, so out of the box without custom code, the module is not usable. On the API side, the basic stuff seems to work correctly. That is: creating a registration; creating registrants;, using a content type (or a bundle from an other entity type) as event; associating a content entity type (person/identity) with a registrant. In the code I also came across things I do not use, so it could be that these do not work. That is (probably among others): wait list, groups and rules. I also do not do anything with capacity/maximum registrants in my custom implementation, but it looks like that feature is covered by the automated tests.

Oh, and I think I fixed all the issues on the RNG configuration forms. So you can configure event types, registration types and registrant types in the UI. And you can create events in the UI. Users just cannot register for an event in the UI.

I was trying to install the module in Drupal 9.3.16 using the version 3.0@alpha. That didn't work because require Drupal 8.8.4. I was able to successfully install it using version 3.x-dev.

@yaach
I did not create a new release yet because the module in its current state is not usable without custom code in my opinion. Users cannot register for an event in the UI that RNG provides.

@MegaChriz thanks for clarification. I would add that after installing the module it broke the View offered by the Calendar module and using a date range field type.

Thank you @MegaChriz and @yaach. I got myself into a pickle trying to install on d9.4.

@yaach was there any issues since you installed other than above comment re breaking the View by calender module. I am getting the message "The service "rng_easy_email.dispatch" has a dependency on a non-existent service "easy_email.handler".

When I uninstall rng module, I get various other messages, and the website is stock "...unexpected error". The service access_check.rng.event_registrations_allowed" has a dependency on a non-existent service "entity.manager".

I am trying to avoid having to reinstall the whole site from scratch!

Try the dev version first. Maybe I should release a new alpha despite it being unstable? (The UI for registering for an event is unstable.)

@MegaChriz, thank you for your prompt reply. Will do that.

Just to feedback on install of rng:3.x-dev on D9.4, I finally got this installed but after having to grapple with this message 'The service "rng_easy_email.dispatch" has a dependency on a non-existent service "easy_email.handler".' which prevented the process and persistently threw a "this website has encountered an error ..." message.

I am not sure if what I did was the solution, but it seem to work.
In the rng_easy_email.services.yml file, I deleted the "@easy_email.handler" dependent object in the service 'rng_easy_email.dispatch' ...
I considered if swiftmailer, a dependency of easy_email, has been abandoned and symfony/mailer is advised, then @easy_email.handler could not be that important.

Any pointers would be appreciated.

@Maplinx
I see that "RNG Easy Email" is a separate module in the project. I don't have that one installed, so that's probably why I didn't ran into @easy_email.handler issues.
So perhaps it would be good to uninstall that one. I do see that it doesn't declare a dependency on an other module (other than RNG), so perhaps it should do that: https://git.drupalcode.org/project/rng/-/blob/3.x/rng_easy_email/rng_eas...

I haven't checked if there are other places in the code where @easy_email.handler is required. I'm on mobile right now, so that's harder to check for me right now.

@MegaChriz
Thank you for clarifying this.
I dont recall specifically installing the rng_easy_email module. Just checked composer.json and its not listed. It seemed to me it came with the installation of rng itself. It has been more trouble than not in my case so I am glad it is not a requirement. omitting it seems to work okay.