Action Step Icons in ProcessView now require ActionTemplateView [2019.3.5]

This appears to be a breaking change in 2019.x

People with ProcessView permission for the project can not longer view the process without a bunch of broken icons. This appears to be because Step icons are now restricted to require ActionTemplateView permission.

Adding ActionTemplateView opens up the library and allows displaying all variable values and source code for Step Templates. Which should not be required, just to have the ProcessView.

Niether can you deny ProcessView as the Project ‘Overview’ tab will not display without ProcessView.

So there is a cascading rabbit-hole of ProjectView -> ProcessView -> ActionTemplateView, where each necessarily requires the next, rendering having separate permissions pretty ineffective.

Having worked with the permissions a bunch now, there appears to be a generate design issue that permissions don’t differentiate between ‘List’ and ‘View’ as other APIs do e.g. AWS *List versus *Describe. This leads to a whole bunch of gotcha cases such as described above.

  • ProcessView should have access to the icons, or
  • There should be an ActionTemplateList permission that grants access to Step names and icons, or
  • ProcessView should display no icons or display generic icons if ActionTemplateView is not allowed

Hi Aaron,

Thanks for getting in touch. ProcessView is used to secure not just the process but the Channels, this seems to be the main issue in your way to lock down how a set of users will interact with Projects.

When a deployment process contains steps that are from the step template library, it is true we currently require the user to have ActionTemplateView.

There’s some history to the granularity of the permissions, when Octopus was simpler they made sense. As things became more interconnected the granularity was slightly deceptive. Prior to 2019.1 we could not guarantee we were not leaking data via an API because it happened to make a request for “supporting data”.

We made a decision that we should be secure by default. Your suggestions are reasonable but it would require a fair few changes in how data is retrieved for deployment processes.

Unfortunately for the time being you will have to make the decision to grant ActionTemplateView access to a set of users to see Projects that do have step templates that are part of their deployment process.


Thanks for the background @nick. A laudable clean-up to ensure a secure API. I understand that for right now, the ActionTemplateView permissions is required to see the Step icons.

From a naiive user perspective, looking at ProcessView, it seems silly I can’t see icons. And as an admin user, providing source code level access to Step Templates seems a bridge too far, just to share the icons.

The icons is the only reason ActionTemplateView is required by the UI when viewing the process. Unless OD users are in the habit of using stenography to store passwords in their icons, I’m for leaking the icons :smile:

Or else an option or behavior for the UI to not display any icons or substitute a generic icon.

These are the links that leads to the broken image in the URI:

1 Like

Thanks for that extra information.

We agree it does seem like anther bridge to cross. We’re discussing what we can do to improve this area for this type of scenario.

I’ll get back to you when we have something concrete to share.


1 Like

Hi @nick, how did the discussions go on this? Will limited access users eventually be able to view the Process View without the broken icons? Right now full access to ActionTemplateView including source code and the Library is required, merely to display those icons in the Process View.

Hi Aaron,

Thanks for checking in. I appreciate where you’re coming from - you want a locked down set of access for your users and want them to have a good experience, broken icons conflicts with that.

We don’'t have any immediate plans to fix this as we’re not working on anything in that area right now.

But I have raised it in our backlog so it can someday be prioritised:


1 Like