🇺🇸United States @john.oltman

john.oltman → changed the visibility of the branch 3520065-migrate-row-remove-empty to hidden.

john.oltman → created an issue.

Thanks for letting me know things are working now! Glad it worked out. Email delivery can be a little tricky at times.

In the latest version of the module 3.4.2 the field formatters have options for showing "reason text" if registration is not available. So you shouldn't require a special template to get some basic text output. See if that helps.

john.oltman → created an issue.

john.oltman → created an issue.

The confirmations are separate. So disabling registration_confirmation only disables the "registration completed" email. Disabling registration_waitlist disables the "you were put on the waitlist" email. They are intentionally completely separate, and should remain separate.

Moving all confirmation code to registration_confirmation module would mean...

You aren't moving anything. You are adding new functionality (admin notification) to both submodules. The functionality is similar in both, and if you want to add some code to the core module in Notify/RegistrationMailer.php that the new functionality can share, that is fine. But don't move any code around. Just add similar code to both submodules.

What you are proposing would create dependencies between the confirmation and waitlist submodules that we don't want, forcing users to always enable both. We can't do that, they have to be separate, waitlist functionality must go completely in the waitlist submodule and confirmation similarly completely in its submodule. Regarding sharing - they both already share an action - I'm not sure how much more can be shared. If you want to add another method to Notify/RegistrationMailer.php (already exists) that would serve both modules, that can work. Thanks for looking into this!

john.oltman → created an issue.

Added new filters for:

* Host entity spaces remaining
* Host entity spaces reserved
* Host entity registration count

Committed to dev branch and will be in the next release.

john.oltman → created an issue.

Thanks @wattdesigns, the new submodule concept is out. What is on the table is the CC you suggest - and @milos would also like the option to have a different message to an admin. If/when he submits this work, your CC will be in there, so you'll be covered. The extra message field does not complicate things so much that it puts this beyond reach.

Looked into those modules and they are not suitable in my view - the integration paths are difficult and each has issues. For example sm has a very small install base, and message requires too many other modules as dependencies. Workbench works with content and adapting for registration would be a major effort. In short I think the best way forward for this particular need is either in a custom module, or adding to the confirmation and waitlist submodules of registration. I am comfortable with any decision you make - custom is probably slightly easier so I understand if you go that path. I promise if you do decide to take on the changes to confirmation and waitlist that I will review quickly and get your code merged as soon as practical after you submit an MR. Thanks @milos.

Perhaps there should be a checkbox (by default checked), allowing to send either a copy of the user confirmation message or a separate message?

I agree with this.

Thanks for posting this issue @daniel, I committed the fix to dev branch and it will be in the next release around May 4. You will need to first assign a default value to the field using the standard widget (i.e. assign a Registration Type to the field). After saving the default value, you can switch to using the read only widget, and you should select Registration Type as the formatter for the read only widget settings. If you don't do it this way, the registration field is essentially hidden on the node form, which defeats the purpose of using the read only widget vs just disabling the field on the form.

Agree that an admin needs a different confirmation vs. the registrant. Also agree this is getting too big and unwieldy - the modules you mentioned look interesting. Let me look into those and see if maybe an integration submodule, rather than more code in registration_confirmation, is a better approach. I'll research and get back on this issue within a day or two.

This issue is for notifying admins when the Email Registrants form is used (via the Manage Registrations area) - not on registration confirmation.

Thanks @milos - if you are going to code it, should it be incorporated as an addition to the existing registration_confirmation submodule? That would make more sense to me than a new submodule. Basically it would add an admin email field to the existing form, above the subject field, perhaps with a description like "Send a copy of the confirmation to this email address". Maybe there would be a checkbox for "Send a copy to the author of the host entity" as well.

Thanks @milos, let's keep things in this issue - this can pop to the top of my to-do list. I'll get the filter etc into the next release, I'll use this issue. And yes - fresh documentation is needed for all features of the module - that is coming over the next few months.

Hi Andreas, you should not have the "Views UI" module enabled in Production - that is used to maintain or add new views listings, and it adds contextual links that can occasionally interfere with other elements on the page. If you uninstall it (drush pmu views_ui) all of your listings will still work, but the contextual links for doing maintenance will disappear, and the Commerce Inbox links will be accessible again. The reason it works with Views UI enabled for the native Commerce listings like Orders and Products is those listings happen to have an action button (Add Product etc) in the upper left - that causes the Commerce inbox link to slide up, where the Views UI contextual filter link no longer interferes.

Please open a new issue in the Commerce Invoice issue queue for that other unrelated problem.

john.oltman → created an issue.

Could be - I'll reach out on Slack

@joelpittet thanks for posting this, your destination plugin looks good, glad you found a solution. However, I was not able to reproduce the error in my test environment - do you have multiple languages installed on your site by chance.

The Calendar module is basically unusable at this point for anyone, from what I have seen.

However, Registration integrates nicely with the Calendar View → module out of the box.

john.oltman → created an issue.

This patch includes a 1 minute refresh, so that new usage is shown. The previous patch will only show changes to existing usage.

If the user has access to the admin theme, the current state is already shown in the Advanced area, even if the user cannot change state. Closing issue - can be reopened if someone needs this for a user without access to the admin theme.

VBO is already supported, but no error message is given if the new state is not valid, the operation is simply skipped silently.

Adding an error message.

john.oltman → created an issue.

Committed to dev branch and will be in the next release in a week or so.

Thanks @joville I think that makes sense - the "toRenderable" function does exactly what you are proposing - except your way removes the need to render the link right away, so it simplifies the change (we can then remove the code related to rendering). And as you mentioned delaying the rendering allows for more theme flexibility for the link.

john.oltman → created an issue.

Please double check this. Perhaps the second email was trapped in a spam filter. I ran your Steps to reproduce in a test system, and it worked perfectly, with the second confirmation email sent as soon as the auto fill completed. The emails are sent to the registrant.

This turned out to be an issue in the custom theme that the OP was using.

Re-roll against 2.0-beta23

Re-roll against 2.0-beta23

Thanks for this enhancement. A couple of things:

* The pipeline is throwing phpcs warnings. Look like easy fixes.
* We'll need a test added to RegistrationLinkFormatterTest.php (in tests/src/Kernel/Plugin/Field/Formatter)

Browse to content you authored and you should not be able to register for it. Make sure you enabled your module and cleared cache first. It does not change workflow that will happen in the next release.

Here is some code you can put in a custom module:

use Drupal\Core\Access\AccessResult;
use Drupal\Core\Session\AccountInterface;
use Drupal\registration\HostEntityInterface;
use Drupal\user\EntityOwnerInterface;

/**
 * Implements hook_registration_create_access().
 */
function mymodule_registration_create_access(AccountInterface $account, array $context, $entity_bundle) {
  $access_result = AccessResult::neutral();
  $parameters = \Drupal::routeMatch()->getParameters();
  $host_entity = \Drupal::service('registration.manager')->getEntityFromParameters($parameters, TRUE);
  if ($host_entity instanceof HostEntityInterface) {
    if ($entity = $host_entity->getEntity()) {
      if ($entity instanceof EntityOwnerInterface) {
        if ($owner_id = $entity->getOwnerId()) {
          if ($owner_id == \Drupal::currentUser()->id()) {
            // Disable registration for content the user authored.
            $access_result = AccessResult::forbidden();
          }
          $access_result
            ->cachePerUser()
            ->addCacheableDependency($host_entity);
        }
      }
    }
  }
  return $access_result;
}

john.oltman → created an issue.

Is this a fresh install, or you are upgrading an existing install of the module?

Any other contributed modules enabled besides registration? If yes, disable those one by one and see if it makes a difference.

Another option is to install 3.3.1 and see if that works for you.

Worst case I may need a dump of your site to debug it - but let's cross that bridge later if we need to.

I am guessing this is something specific to your site and installed modules. Do you have the Field Permissions module installed by chance? Can an anonymous user get directly to /node//register?

Thanks for that info. Typically, the ability to create content is reserved for "trusted" users, e.g. a "staff" role, where the staff can be directed not to register. That doesn't sound like the case for your site - however a custom module with a small amount of code can prevent users from registering for content they authored. If you are interested I can post some code here for you, let me know.

I agree that an option that would prevent users from being able to complete their own registrations is a general use case that is missing - there will be a new release of this module in 2-3 weeks, I'll add that option soon so it can be in that release. I will adjust the title of this issue to be more clear.

If I have misunderstood your "ask" please let me know.

You must have the registration module checked out, instead of it being installed through composer. When you check the module out from GitLab, the version info is not appended to the .info file, so Drupal can't find the version number. Move the checked out module elsewhere (in case you have any changes or stash) and then do a composer install and you should be good to go.

Any reason why not this for multilingual

That works too @jonathanshaw

There could certainly be other convenience actions and conditions, but really all that's required at a baseline are making some tokens work

I added new tokens @freelock, these will be useful for ECA but also for others.

[node:registration-host-entity] - that gets you the host entity tokens (assuming there is a node bundle with a registration field)
[node:registration-host-entity:registration-count] - that tells you if there are existing registrations for the node
[node:registration-host-entity:*] - tokens for the host entity (these align with some of the HostEntityInterface methods)
[node:registration-host-entity:settings] - that gets you the settings for the host entity
[node:registration-host-entity:settings:*] - tokens for registration settings fields and properties
[node:registration-host-entity:settings:id] - that will get you the settings entity ID - and it will save the settings entity if it doesn't exist in the database yet, so an ID is always returned. In this way you can use the ECA entity load action without worry.

Those tokens will help you with the importer scenario.

If you are coming at it from the registration, these tokens are added:

[registration:settings:*]
[registration:host-entity:*]

I hope this helps. Sorry it took a while!

Can you post the permissions currently assigned to the role, so I can help you. There isn't enough information here yet. Also please post which submodules of Registration, if any, are enabled on your site (Registration Workflow, etc). Thank you.

john.oltman → created an issue.

Does this still happen after the upgrade to 3.1.5 and 3.4.1? Can you send a screenshot or the original native language text if yes.

Thanks for the issue @dgwolf I will take a look within the next day or two. If the modules actually updated via composer, you are probably good to go, but the lingering message is something I want to resolve.

Thanks @franceslui for posting this example!

We connected on Slack but for anyone else who comes across this issue.

You need to upgrade Commerce Registration to this release:
https://www.drupal.org/project/commerce_registration/releases/3.1.5 →

That provides the event subscriber needed for commerce product variations.

john.oltman → created an issue.