Thanks for getting in touch! I'm terribly sorry about the delay in getting back to you. I've had a couple discussions with my team concerning your questions.
Firstly, you're correct that library variable templates can't be scoped to an environment, so unfortunately that's not possible if you need environment scoping.
You make a good point regarding the UI of the tenant variables page being unfriendly for large numbers of variables like in your scenario. The only workaround we can think of for the moment is to manage these authorisation variables as JSON or XML, and store the entire set for each tenant as a single variable. This would resolve the large number of variables, but it depends on whether you can modify your process to work with this.
This point you raised has started a conversation about re-thinking the tenant variables page to make it more usable for large numbers. It's currently ongoing, but I'll be sure get back to you soon with any updates regarding this.
I hope this helps for the time being! I'm sorry it's not better news, but thank you for bringing this to our attention. It really helps us work towards continually improving Octopus. :)
We're currently working on completely overhauling our UI for the upcoming 4.0 release, so this will be addressed after that release. If you're interested in checking it out, we've shown some of the UI changes as they are right now in our most recent TL;DR meeting, and you can see that in action here. :) https://www.youtube.com/watch?v=0PPI49Ld-vE
Don't hesitate to reach out if you have any further questions going forward.
at first, I thought the JSON/XML suggestion might only make things more cumbersome, but you've prompted me to return to the variable substitution documentation and I note that you now have native JSON parsing (we've come from 2.6). It might actually be a better, more manageable, solution than our current one-variable-per-authorisation-rule approach since they're all of a kind. I'll try to sell it to our support teams.
That said, even were our authorisation rules reduced to one variable per customer, we still have over 100 variables which will make the tenant variables pages unwieldy. So I'll be following your raised issue closely. I watched the 4.0 video you linked, by the way, looks very promising.
Thanks very much for your considered response and suggestions. I've been repeatedly surprised by the responsiveness and extra mile effort of the OD support staff. You guys are great.
I'd like to keep this discussion both open and public until this weakness with OD multi-tenant support is addressed. The associated issue raised in September 2017 appears to have stalled and the latest version v2018.5.7 continues to provide an impractical and inconsistent interface for tenant-level configuration management.
Note that this issue precludes us from migrating approximately 300 deployment projects, which we currently manage 8 products for 30 or so tenants apiece, to 8 far simpler projects. We're also unable to effectively take advantage of your Channels feature.
The current interface prevents us from filtering variables by name and value, and requires that common values among environments are defined per environment. All of which you make available on project-level and library variable set screens, but not for tenants.
Can you please acknowledge the inconsistency and provide an update on this one?