Brilliant thanks!
I understand that there will be some UI for admins to review the new permissions and take action, however, how will the admins be notified if there is something to review? Not all admins will come to the Connected Apps screen on a daily bases, so how do we get them to go there when there is something to review. Ideally the platform itself can be used to notify the correct people to take action.
This is really important. We need a notification system or someway of getting hold of the admins. Today we don’t have their contact information.
I am keen to get feedback on this particular feature, what its intended use cases would be, and how crucial it would be.
I am keen to get feedback on this particular feature, what its intended use cases would be, and how crucial it would be.
Well, I am not sure I completely get this feature. Does it mean that I can now install on a dev site a previous major version? That is we have an app with versions 2, 3, 4, 5 - and then I can install version 2, 3, 4 and 5? So I can also target to install that version in a particular dev environment? And then be able to upgrade the app and see how a migration will go?
Best,
Eckhard
Hi James,
In addition to display conditions, could Atlassian consider exposing the permission information through trigger filter expressions as well? This again helps with the goal of not being forced to pay for invocations that would never complete properly anyway due to absent permissions.
I would prefer this to be offered as opt-in for marketplace partners and customers. Default should be streamlined, lightweight and automated. Customers should be able to decide their own risk profile on immediately accepting updates automatically or not. But not infinitely. They can always uninstall. But if I want to offer more control for customers that want this, it’s my commercial choice to offer it.
Okay, yes it means you can install previous versions from an environment (with forge install) and then trigger an update to test the migration path.
Yes, say you have an app with a dev environment with versions up to version 5, and you wanted to deploy a new version 6 that would trigger an upgrade for customers.
You could deploy version 6, then install an older version (2,3,4,5) then use forge install --upgrade to migrate to the latest. Then uninstall and repeat the test with the other versions as well.
To be clear, this would only work within the same environment. It would not let you use production environments and then upgrade to an un-released version in staging or dev.
Concur with @james.dellow . All this complexity to allow/require customers to cherry pick permissions for an app that should be all or none. Wouldn’t it be simpler to align marketplace apps with the Atlassian apps approach?
If the customers no longer wants the app due to expanded permissions they can uninstall. No action means they receive the update, just like Jira and every other SAAS offering.
Regards,
Chris
Digital Rose
Yeah exactly @Chris_at_DigitalRose!
The justifications I’ve heard for the over-complicated approach comes down to:
Point one doesn’t make sense because all that requires is Atlassian changing a legal clause somewhere. Point two with an opt-out model does provide customers full control if they choose to exercise it.
One would think the Atlassian legal team can find the balance between:
From an app’s perspective we’d prefer forced updates as the simplest solution, mainly because of these advantages:
If for whatever reason this cannot be, I can see the benefit of at least solving for advantage 1 (no customer on old app versions), because for us that is more painful than more complex code due to permission checks. At least, the permission checks give us app developers real agency in nudging/forcing customers to approve new/optional permissions (i.e. the level of heavy-handedness that Scott mentioned).
Of course, for this to be really meaningful, we need a way to address the decision-makers, i.e. the admins. For that, I second Mark and Daniels posts:
Hi @aragot,
Could you specify which parts are open to interpretation and the various ways to interpret them? We are happy to clarify any unclear points.
The part which says “Here’s what it will look like” does not outline the design decisions, but the upsides of the decisions,
We acknowledge that resolving the issue with app versions requires us to improve how app developers supply release notes and how they are delivered to customers. This would include optional features, such as bundle of scope and/or egress permissions, managing app updates through release tracks, and more. These enhancements will be addressed in future milestones, and design decisions are still pending. We encourage you to focus your feedback on decoupling app code version from consent. Thank you.
Well, let me put the use case I would see: I am planning on upgrading, or the new change rolls around, and I want to test those before the rollout, so I want to to do this:
It seems that being able to test this after the fact, ie, when I have rolled out a new prod version, seems better than nothing, but it also seems late.
It would not let you use production environments and then upgrade to an un-released version in staging or dev.
But isn’t that exactly what you would want for testing?
Best,
Eckhard
Thanks Scott,
That is also a great suggestion and we are investigating the feasibility of adding conditions to product event triggers.
Hi @Corentin,
For this one you should be able to determine whether a data security policy is the reason why the app can’t access it: https://developer.atlassian.com/cloud/confluence/data-security-policy-developer-guide/#confluence-data-policies-for-existing-rest-apis It is only available for Confluence though. I do recognise this is only one of many reasons, but hope it helps anyway.
Cheers,
Agi
Hi @EchoZhangjie , thanks for outlining that use case.
We’re talking about the ability to install old versions in an existing environment.
To get old versions of the app into a test or custom environment before release, it’s assumed the developer still has access to the code that produced the old version of the production app, and can deploy it again to another environment (or has already deployed it previously during development).
However, some breaking changes can make this difficult and may require code modifications to bring the old version to a working state. If this is the case, deploying the old build without any code changes would prevent testing anyway. Either way, work would be needed to bring the version up to a working state to set up the test case.
I’m just confirm things already said in this forum.
Importance order:
Low prio for us: Allow to expand the permission scope and make it optional, as described here: Aka: Most likely we would use it to more or less ‘block’ the whole app and say you need to updated it. To avoid having to support different scope configurations. But of course that depends on the actual case.
I want to address the current transitionary period from Connect to Forge. A lot of vendors are either currently in this situation or will soon be.
This means transitioning from the few permissions we used to have on Connect to more granular Forge ones. Each of those releases would require a permissions update. What would help in this case is a built-in mapping that would assume that if the user had permission ABCD in Connect, then permissions A and C in Forge would go over as a minor update without requesting approval.
As it stands now, we’re looking either at releasing every single update as a manual approval version or waiting to release everything in bulk, which blocks us from any useful releases in the meantime and collecting valuable feedback on the changes.
On the topic of using the app without certain permissions, it’s something I’ve had to work with on a different platform and let me tell you it is a nightmare for everyone involved where you have to consider how the app is going to work without any random combination of permissions. Users will simply be confused and blame it on the vendors.
The idea of having a default path that keeps customers on the most-recent version as automagically as possible is important - and keeping that default path simple for and visible to customers is equally important.
I do like the idea of being able to bundle together app features and permissions into units that an admin can manage. I do wonder how broadly this is applicable, as well as how it interacts with other options for presenting buckets of functionality to customers (e.g., editions) and how customers will react to having some number of different ways to get to the same thing. This seems like an opportunity for customer (and support) confusion. The impact really depends on the level of adoption, though.
I also wonder about customer with strict change-management policies and how these proposals play out for them - particularly if there are a number of options and each vendor solves the problem differently. I know this begins with the assumption that this is a case that is out of scope, but I don’t understand why that’s a valid assumption (I can think of a couple of reasons, but I’m not sure what Atlassian’s reasons are).
I still think the best way to handle upgrades would be automatic, similar to AndreasEbert’s comment or james.dellow’s comment above. As I wrote last year in RFC-71:
Throwing out some ideas:
Let individual admins decide if they want to automatically auto-upgrade apps or not through a configuration option.
If admins do enable auto-upgrade, let them decide if they’re OK with automatically upgrading permissions within a limited set of scopes only (for example, if the app has the equivalent of Connect READ permission only, then auto-allow the app to inherit permissions to READ any other object type, but don’t allow auto upgrades to WRITE-type permissions). Or perhaps the admins can also decide that they want to automatically accept all permission upgrades. Maybe there are also options to consider here related to accepting Forge egress permissions and other sensitive features.
For permission changes that are not auto-approved by config setting, give admins a (say) 14-day review period to review the proposed upgrades (while the app is still running the prior version with old permissions). Also allow the admins themselves to decide what to do if the delay expires without action on their part: either disable the app (until the change is manually approved later), or auto-upgrade upon expiration of the review period. This ensures that, after a certain window, there are no active apps running old code, and it allows admins to tailor the upgrade strategy to their security policies.
Nag product admins sufficiently during the review period to get them to take action (and continue nagging afterward if there are disabled apps). This might include sending emails, banners in the UPM or the fancy new admin app interface, pop-up flags on the dashboard when admins log in, etc
Have CCP (or whatever) enforce that new permissions be accepted before letting the “renew” button be clicked for an app.
That having been written, the scope of this RFC suggests that the Forge team is looking in a different direction.
My suggestions in this thread to be able to completely brick our own apps (by turning off modules and triggers if permissions are not correct) is second-best, but it is probably workable if the “better” approach above is not in scope for the short term.
One of the main downsides of the latter approach is that it imposes a lot of work on every app vendor, since we would all need to define the current permission set, tag every module and trigger, and generally jump through hoops. Multiply this by a thousand vendors and there is a lot of effort that could have been avoided.
What about creating some sort of single top-level flag in the manifest to the effect of “please treat the app as unlicensed if not all permissions X,Y,Z are present”?
Vendors already need to handle the condition of being unlicensed (reducing the duplication of effort), and the handling of “apps without license” case is probably very close or identical to the scenario we would want to present if the user had an outdated app. If needed, you could probably also annotate the license check APIs to identify this specific case (user is actualy licensed but app is outdated), in the event that the app needs to deal with it differently.
Ideally, apps in this state should have this information surfaced in the UPM (or whatever it’s called now), calling out to the admin that they need to upgrade.
Also, when Atlassian ends support for Connect (~1-1/4 years from now), how does it plan to deal with customers who are still stuck running older versions of Connect or Connect-on-Forge apps, but who have not upgraded to the Forge version due to permission changes and the absence of admin approval?
Atlassian will eventually have to figure out some sort of solution for this, and figuring it out sooner rather than later could let everyone benefit from the same solution here.