When an app requires manual customer approval, how long before the email sent to admins?

Marketplace General Discussion
1

For the first time in five years since first listing, one of our Connect apps has required an additional scope to be added to its descriptor (“ACT_AS_USER”).

According to Upgrading and versioning cloud apps, an increase in scopes is considered a minor version update which requires customer approval:

Even though your app is automatically updated in the Marketplace, certain scenarios require customers to manually approve your app’s update in the UPM. These changes correspond to minor version updates in the table above. In these cases, we automatically send emails to the product administrator so they can approve and update the app.

As I write this, the timeline is:

  • The new app descriptor (with increase scopes) was deployed approximately 19 hours ago
  • Marketplacebot detected the new descriptor approximately 30mins after deployment, and automatically created the new minor Marketplace version.
  • In our production Confluence instance, the Manage Apps page shows the new update available

Wearing our “product administrator” hat, we haven’t upgraded our own instance to the new version yet, as we wanted to experience the customer approval process for ourselves.

It has now been 18.5 hours since the new version was first available, and we have not yet received an email asking us to approve the new scopes/version for our own instance.

Our app logs indicate that there have been no hits to our /installed endpoint since the new version was created; which we’re assuming means that either:

  • No customers have received the approval email; and/or
  • No customers have chosen to update to the new version yet

I appreciate that it is a weekend (and even a long weekend here in Sydney); so this could be expected.

If anyone else has experience with increasing the scopes of their apps, as a product administrator, how long should we wait to receive the approval email before we start getting concerned?

To be clear, the app still functions using the previous descriptor; so we’re not too worried at this stage.

Normally for automatic upgrades, we see these start rolling in shortly after the Marketplacebot detects the new descriptor; so we would have expected that emails to product admins asking them to approve the new version would have been received by now.

5 Likes
2

Interesting, I didn’t know this! But just as you said I suspect these emails either aren’t sent, or even if they are, aren’t being read. We are in a similar situation in that we added the ACT_AS_USER scope to our app and were wondering how long it would take customers to update. Now, about half a year later after we deployed the change, we still have a handful of paying customers that didn’t update yet. We are planning to soon contact them manually as we don’t want to support the old infrastructure/code for them anymore.

Cheers,
Sven

3 Likes
3

Thanks Sven.

Luckily for us the feature* that needed ACT_AS_USER is part of our apps configure page, accessed via the Manage Apps screen.

So we’re hoping that admins on their way to that screen will see that an update is available.

(* One of our API endpoints needed to check that the current user has administer rights, and it seems that ACT_AS_USER is the only way to get the current users permissions)

1 Like
4

@scottohara you don’t need ACT_AS_USER for this, see How to check if a user can administer Confluence in a Connect app

1 Like
5

Hi @marc ,

This is interesting, because that seems to be exactly what we tried without ACT_AS_USER, but the userAccountId in the request context was the app account, not the end user account.

It was only once we added ACT_AS_USER scope that the JWT context became the end user.

Basically what we’re doing is this:

In the (browser) client, get a token and call the API endpoint:

AP.context.getToken().then(token => {
  $.ajax({ url: "/some-endpoint", headers: { "Authorization": `JWT ${token}` } });
});

In the (ACE) server:

app.get("/some-endpoint", addon.authenticate(true), (req, res) => {
  const client = httpClient(req).asUserByAccountId(req.context.userAccountId);

  client.get("/rest/api/user/current?expand=operations", (_, apiResponse, body) => {
    let admin = false;

    if (OK === apiResponse.statusCode) {
      const { operations } = JSON.parse(body);

      if (undefined !== operations) {
        admin = operations.some(({ operation, targetType }) => "administer" === operation && "application" === targetType);
      }
    }
  });
});

Is there perhaps something else we missed? We would certainly love to remove ACT_AS_USER if we don’t actually need it.

6

Coincidentally, just today ACE released a new version (7.1.5) that adds support for checking for admin permissions as middleware:

module.exports = function(app, addon) {
  app.get(
    '/admin-resource',

    [
      addon.authenticate(true /* accept context JWTs */),
      // only allow product admins that also have access to read the current page
      addon.authorizeConfluence({ application: ["administer"], content: "read" })
    ],

    function(req, res) {
      res.render('protected');
    }
  );
};

So this should simplify things greatly, and remove the need for ACT_AS_USER.

Shame that this is about 2 days too late, as it would have avoided the minor version bump in my app.

7

@scottohara Your code looks ok, except we use a different API call:

let httpClient = addon.httpClient(req);
let accountId = req.context.userAccountId;
let url = '/rest/api/user?accountId='+encodeURI(accountId)+'&expand=operations';
...

This allows to check the admin permissions of a user. Without needing ACT_AS_USER.

1 Like