Corrections.
> Why you don't like explicit lock actions?
I misinterpreted your statements above, looks like we both like
explicit locking.
> add_permission_to_provisioning_manager (also adds to "manager" role)
> add_permission_to_provisioning_reader (also adds to "reader" role)
>
> Ok, we discussed the migration path. We should be (with small changes*) able
> to detect whether users modified existing Manager role. In case they did, we
> would rename them to "Customized Manager" and create new Manager role with
> default permissions but locked. Locked means no changes to
I like the idea of having plain ActiveJob for simple background tasks
and providing tasks/dynflow for complex orchestration processes (also
available via ActiveJob API). While I understand whole motivation why
dynflow/task was created in the first place (providing a way to do
one-way
It's be nice to be able to turn some of these off, I might not care about
some types of notifications.
I think a simple "don't show this type of notifications again" on the
notification would be great.
I don't know if this is already possible?
Also a couple of more notification suggestions:
-
Shimon Shtein writes:
>> It would be on plugin maintainers decision.
> What would be a maintainers decision? The fact that the task will run only
> on some setups? IMHO It's a bit annoying.
>
> About the automation, my solution basically removes both
>
> It would be on plugin maintainers decision.
What would be a maintainers decision? The fact that the task will run only
on some setups? IMHO It's a bit annoying.
About the automation, my solution basically removes both
foreman_remote_execution:rubocop and the enhancement (And deleting code is