JIRA installed event


I am trying to do an initial setup when the installed event is triggered. I want the links to the add-on to be visible to a certain set of users (specifically project leads).

My idea is to add an entity property to the project leads and by that the add-on link will become visible. (I am using atlassian-connect-spring-boot) Unfortunately I am not able to add the property to the user - getting 401, in atlassian-connect.json I have requested for the Write permission). To me it seems that the installed event does not have the user details available who installed the add-on and therefore is not allowed to make the request - am I correct?

Do you have any other recommendations how to achieve the same result, limiting the visibility of the links to project leads only?

Hi @oliversoop,

It’s not exactly the same, but it will quite likely be functionally equivalent (and substantially easier) for you to use the user_is_admin and/or user_is_project_admin conditions.

+1 to Dave’s suggestion.

@oliversoop, your add-on will not have access to Jira API’s until some time after you have returned from the installed callback. Currently, we fire the enabled webhook when your add-on has received the appropriate permissions, but that contract isn’t strictly defined.

I am using /enabled hook to store properties in JIRA

app.post('/enabled', addon.checkValidToken(), function (req, res) {
        var addonClient = new AddonClient(addon.httpClient(req));
        var onboarding = new Onboarding(addonClient);
            .then(() => {
                addonClient.logger.info("preconfiguration finished");
            .catch(error => {

Also, to write USER properties you need ADMIN scope, not just WRITE scope. When you think about it this makes sense, only admins should be able to update users properties. You can retain merely WRITE scope of you use AP.request in the front-end to update the briefing users properties.

+1 on Dave’s answer - not because of the enabled race condition (there is one and don’t always rely on webhooks making it to you - they’re not fully guaranteed).

Since a user can be removed from being a project admin in several ways(or granted the permission) that you might not always catch - using the built in project_admin conditions is the safest and easiest way.

1 Like