Applying publishers to receive notifications should not be a config setting

[elfacht]

What are you trying to do?

The setting Publishers To Receive Notifications can be changed on production environments, but will cause changes in the config.yml. These changes will be overwritten by the next deployment.

Making changes here:

… will cause this:

This has a huge conflict potential for deployments!

What's your proposed solution?

Settings which are available in production environments should be DB based and not config based. These changes should only take effect on the environments where they were applied. Right now it requires a developer to add/remove publishers, although there is a public setting.

Additional context

No response

[elfacht]

This also causing problems since one user has another ID on different environments, so the settings won't apply on production.

[engram-design]

Those settings shouldn't be accessible unless allowAdminChanges is set to true? You're not meant to edit them per-environment, as they are plugin settings.

And yes, granted selecting individual user elements isn't exactly ideal as a plugin setting value, so we might change that to a user group instead. That'll be a little bit of effort to get around being a breaking change, but doable.

[elfacht]

@engram-design allowAdminChanges is set to trueon our test systems, but not live. This isn't the problem anyway. The problem is, that we have 50+ editors on the live system and their IDs are not in sync with every test system and local dev environments. Therefore setting the users should only be able on the dedicated environments and not by a developer who needs to commit the changes via Git or something.

We are already encounter this exact problem. We can't apply users because we don't have their production IDs in sync locally since user accounts are user generated content and shouldn't be part of config settings.

Users that can create user user accounts (and assign user roles) should be able to assign users to receive publisher notifications. This shouldn't be a developer's job.

[engram-design]

Right, your comment:

The setting Publishers To Receive Notifications can be changed on production environments

Threw me a little - you shouldn't be able to change it on production environments, and you're saying it can?

But yes, I agree that the notification setting should select a user group that you create during dev, then you can associate users to that group per-environment without messing around with project config changes.

[elfacht]

Threw me a little - you shouldn't be able to change it on production environments, and you're saying it can?

That was confusing explained from my site. We haven't deployed it to production, yet. I meant the staging clusters which have the allowAdminChanges enabled in our environment.

[elfacht]

Is there any intention to implement this feature anytime soon? Otherwise we would move on to another solution.

[engram-design]

My concern with this, is it's going to be a breaking change. Anyone currently referencing a User element is going to not work correctly, or have that setting removed, because we can't really translate a User to a User Group.

There's a clunky solution to have two settings for this, one (legacy) for users, the other for user groups, but I'd rather not complicate this setting for that.

My suggestion until then is to download your production database locally, set up the settings, and deploy that. I know that's far from ideal, but I'll look into options.

[elfacht]

@engram-design Ok, thanks for your answer and effort. This is unfortunately not feasible with our environment and workflow, so we have to move on. I will have a look at this plugin from time to time, though.

[MoritzLost]

@engram-design I agree that specific user IDs should never be tracked in the project config. I don't think it's a huge breaking change, as the current solution doesn't really work. It will only work if you create your users in a dev/staging environment and then upload the database to production. This might happen while a project is being developed (though I don't see a good reason to do that). Or shudders it will work if you enable admin changes in production, which shouldn't really be encouraged. Otherwise, there's no way to select user accounts in your dev environment that only exist in a production environment.

But I think there are backwards-compatible ways to address this. You could change the checkboxes field for users to an input field that accepts a comma-separated list of IDs, or an environment variable or Twig template that contains / evalutes to a list of IDs. That's how the built-in condition rules allow you to specify authors without including specific IDs in the project config:

Granted, this only supports a single ID, but there's no reason to use the full condition builder framework for this setting.

Then to support existing configurations, the existing setting could be migrated to a comma-separated list in that field.

[engram-design]

Added a new setting for this for the next release. To get this early, run composer require verbb/workflow:"dev-craft-4 as 2.0.13".