Imagine you have a connection string variable and you want to update it. You would update the variable and redeploy, however if you made a mistake (edited the wrong variable or the new connection string was not live yet) then you cannot roll back. This is even more of a problem if the variable is sensitive as you can't copy it beforehand.

I would like to be able to version octopus variables, this would include:
- Who
- When
- When deployed
- The ability to roll back/forward.

At the moment we have to source control much of this type work, this obviously negates much of the valuable octopus functionality around environment handling/sensitive variables.

Scenario: I am about to promote my new release to production. My release is clean (i.e. I'm not getting the "something has changed warning"). However, a week ago, someone made an errant change to the production transform for a shared library set variable. If I deploy, it will break due to that variable change that I don't know about. I don't have a good way to detect this before I hit deploy.

Request: On the deployment screen for a release, provide the ability to diff that release's variable snapshot against the variable snapshot from a previous release that was deployed to that environment. The diff should only include transforms relevant for the environment in question.

With one of the latest updates, the Dasboard technology has been changes to React Virtualized Grids. We are running a bigger Project with a lot of services that are grouped up in the dashboard. With that new Technology, the scrolling performance and logic on the page got really weird. Sometimes the group is scrolling, sometimes the page. While attaching/detaching Deploy Versions sometimes a white area is shown while scrolling.

In addition we had custom user styles applied by the browser Addon stylish to resize the grid in Dashboards as Element and Text sizes seem to be optimized for Tablets. Before the latest UI updated we scaled the grid way down to have a better overview if all components in a project are up to date without scrolling. Int he original Theme everything is just incredibly huge.
As the new Technology is calculating everything by JavaScript and rendering inline styles, attaching/detaching Elements from the DOM, we're not able to do that anymore.

If this is the planned way to go it would be very helpful to at least support custom theme packages which could be added e.g. by Octopus Administrators.

In the current state dashboards completely lost their usefulness for myself and are adding a lot of manual research overhead in the daily work.

I'm working on code for a Terraform module for modifying Octopus Deploy configuration, and when we have variables with the type set to Sensitive (or IsSensitive=true), Octopus understandably does not return the value of the variable.

However, this means it is impossible to determine if the value is set correctly.

One workaround would be to provide a hash (even a salted hash) of the value when it is set. Then we could compare our hash against the hash in the API, and if they don't match then update the sensitive variable.

E.g. A new field called `ValueHash` which is `sha1(Name + Value)`

Any plans for introducing custom pages or plugins? It would be really nice to be able to create custom views using the api and have them in the menu of octopus. These pages could also have associated scripts and variables which could be used for viewing logs or trigger a merge or a build of a branch.

Other examples would be viewing all tenants without any deployment option. Or view the lastest commits from a defined source (to get a hint on what is expected in the next release).

I think a lot of users want to use octopus and it's interface a the main platform to get a good overview of everything. But also I understand that you want to keep it lightweight, secure and easy. That is why a plugin possibility would be great.

A option would be to create a external site and then invoke Octopus Rest API and use that as a main platform.

For example I would like a simple button Deploy lastest release to development environment where no options at all is present. It would then trigger a build using specific tags and redirect the user to the deployment. Having to avoid a custom site/app would be great.

Be able to hide "sections" of variables in a project template on a tenant and envrionment. For example: I have single-sign-on configuration in web.config. If the checkbox "Enable Single-Sign-On configuration" is checked is not checked I would like to remove the configuration variables bellow the checkbox.

Having tons of these sections really clutters the overview and making it hard to configure.

Also being able to group variables into +/- sections with a header would be really great.

I would like to extend this even further on a tenant level using tenant variables to enabling features such as the "Enable feature Single-Sign-On" in the example above".

I know you have said that you do not like to make variables and their existance to complex as it could make deployment difficult (I saw a response regarding it in the support forums).

But it could really be as simple as a binding syntax on the field.

Tenant A has single-sign-on. A project-tenant specific variable is set to EnableSingleSignOn="True", default="False"

The project-tenant-environment specific project template variable
UseSingleSignOn could then have it's default value set to the binding
#{configurable-if EnableSingleSignOn}False{/if}

If EnableSingleSignOn is "False" then the default value would always be set and the field would not be visible.

Same goes to the keys of the single-sign-on configuration.
The key "ClaimDomain" would have the default value #{configurable-if UseSingleSignOn}{/if} and would be configurable/visible only if
UseSingleSignOn is set to true.

As you do not support optional variables you can just leave it as a empty string. I am using the workaround of an empty global variable called #{AllowEmpty} which I put in all fields that are allowed to be empty.

In this case I would use #{configurable-if [Single-Sign-On-Key]}{#AllowEmpty}{/if} to allow empty values when the feature isn't active or enabled on the environment.

We have a lot of projects. This means we also have a lot of lifecycles. Everyone seems to set them up differently.

What i'd like to propose is the ability to assign roles to a phase (environments can be kept for backwards compatibility or simple environments).

In this way, we can have only a few lifecycles, and apply the roles to different environments. Say we have Application A, which is assigned the Default lifecycle. Then when create environments, we can assign the "pre-prod" role and it will automatically follow the pre-prod phase progression rules.

This allows the environment manager to specify which progression to follow, rather than having to create unique lifecycles for each.