Incorrect config dependency in shipped action configuration

Note that I opened 📌 Action config entities should have a config dependency on their (entity) type provider Active in core because I do think that in principle the dependency on user is correct because that is the entity type that the action is for. Note that that could in theory be done via an enforced config dependency, but I'm not sure if it's really worth it because user module cannot be uninstalled anyway, so it's quite a theoretical case.

Thank you! Curious if both should be mentioned as dependencies from config affects a install-from-config order

Not sure about #5, because as far as I know all modules will still be installed first even in an install-from-config. But didn't verify that.

However, I agree it does kind of make sense to have a dependency on user module, even if there is no concrete functional bug without it. I was about to write we should fix the core issue I opened to get that dependency for free, but after looking at that one a bit I realized that in core all config dependencies, including those on entity type providers, are handled by the respective action plugins and that the type config property is actually unused entirely. So I think what we should do here is have UpdateUsernameAction add the config dependency on user module.

Added a commit to the merge request which does so by extending EntityActionBase. (For full disclosure, I was feeling bold and used the Web IDE for this, but since there is test coverage for the action (👏👏👏!!!), I hope that's all right.)

@tstoeckler so we can still be sure the action is removed, if the module is uninstalled, if I got you right?

@andypost final review maybe? :)

Exactly 👍

There is no practical difference, it's just that the (non-enforced) dependency gets added when importing the configuration anyway, so this makes the shipped file match the state that will be imported.

Thanks, then let's do it! :)

Automatically closed - issue fixed for 2 weeks with no activity.