It was only part of a discussion, but I want to raise it as an issue. Especially in a larger installation, where many people are involved and have different access rights, this issue causes support effort.
People have rights to admin applications and automations in their own workspaces. However, some automations are connected to apps they don’t have access to. But there is no warning or locking mechanism.
Editing the automation shouldn’t be allowed to users, which don’t have all necessary rights for all involved apps. Currently this breaks the automation, which we think is a bug. Especially as its not obvious - saving appears to be working, but automations start to fail from now.
You know, I just ran into this internally yesterday. We have two different seats. One for doing all of the automation and then I have my regular seat. Sometimes I save over automations and accidentally break them while using my personal account.
I believe that the automation holds on to the permissions from the last user who saves.
I’m not sure of the best way to handle this but I figured it might be worth sharing in hopes it helps to move us closer to a solution.
@dirk_s@1F2Ns, yes this is indeed a problem that still needs to be optimized and that we have already included in the roadmap.
On the one hand, the automations must automatically receive the extension of permissions from the last saver without having to save them again. The loss of permissions, however, should only occur when saving again (otherwise automations will break if the last saver loses permissions).
For overwriting, a warning modal would probably be a good compromise. Complete locking often leads to new problems, such as automations that can only be edited by a very small number of users because the last saver had very high permissions.
Not sure I understand completely: This means, as long as fields with higher required access in an automation remain untouched, the current user can save the flow without destroying it?
That sounds like a smart approach. Does this means:
without proper rights, user can’t create a calculation with a field / record without access - true,
but user can still save the flow changed it elsewhere?
The warning of overwriting should probably state which access right is missing.
@dirk_s I actually meant something different. With the first point I addressed the general problem that when you are editing an automation in Tape you first have to save it so that it receives all newly created apps and the associated permissions.
We already had your suggestion or your idea based on fields, but we had to reject it in the original conception of the automation. The background is the possibility of a security gap. Someone could change an automation that has very extensive permissions and, for example, have data sent to them via email from a salary app that they do not have permission to access, by adjusting it. That is why the automation must always receive the permissions of the last person who saved it to make something like that impossible.
Nevertheless, I understand your problem completely. I think the first quick fix would be a warning modal when saving that the user is now damaging the automation because they don’t have the required permissions and then a direct change of the status to broken if they ignore this warning?