Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-26089

Installing/Updating the plugin directly from manage apps section downloads the jar with name like plugin.3504767<random_numbers>.download.jar

    • 5
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Issue Summary

      This is reproducible on Data Center: (yes) 

      Steps to Reproduce

      1. Navigate to the Manage Apps section and download/install any plugin. For example: ScriptRunner.
      2. Once the plugin is installed, navigate to the directory <JIRA_HOME>/plugins/installed-plugins and you will notice that the jar is downloaded with name like: plugin.3504767825672828476.download.jar
      3. Notice that it has no mention of the plugin name.
      4. If we download the jar manually from marketplace.atlassian.com and upload it using Upload App button, it gets added with the plugin name instead of random numbers as pointed in Point 2 above.

      Expected Results

      Installing any plugin from Manage Apps section should copy the jar name under <JIRA_HOME>/plugins/installed-plugins with the plugin/app name. It is helpful in determining what jar belong to what plugin. 

      Actual Results

      Refer to the Jars highlighted in the red box below:

      Workaround

      Use the Upload App button under Manage Apps section to get the jar downloaded with correct name.

      If you'd like to only view the app names for each JAR, then run these commands:

      cd <shared-home>/plugins/installed-plugins
      for i in $(find . -name "plugin.*.download.jar"); do echo $i; unzip -p $i  atlassian-plugin.xml | grep -Eo "atlassian-plugin [^>]*>" | sed -E 's/(atlassian-plugin)|(plugins-version=".")|(>)//g'; done 
      

      The output should resemble something like this one below, listing the file names and corresponding app names.

      ./plugin.9834594699245328574.download.jar
       key="com.javahollic.jira.jemh-ui" name="Enterprise Mail Handler (JEMH) for Jira Data Center" 
      ./plugin.8297165867298969457.download.jar
       key="com.qotilabs.jira.rich-filters-plugin" name="Rich Filters for Jira Dashboards" 
      ./plugin.6287285435938084735.download.jar
       key="com.atlassian.jira.plugins.jira-slack-server-integration-plugin" name="Slack for Jira Data Center" 
      ./plugin.532409277185381002.download.jar
       key="rw-smart-checklist-biz" name="Smart Checklist" 
      ./plugin.5986725383647808491.download.jar
       key="com.stonikbyte.great.gadgets.server" name="Great Gadgets" 
      ./plugin.16432350874212133862.download.jar
       key="com.codebarrel.addons.automation" name="Automation for Jira" 
      ./plugin.16246789332246523104.download.jar
       key="com.xpandit.plugins.xray" name="Xray" 
      

            [JSWSERVER-26089] Installing/Updating the plugin directly from manage apps section downloads the jar with name like plugin.3504767<random_numbers>.download.jar

            Hi Allan,

            thanks for the update. I'll always appreciate workarounds in general, but workarounds are sometimes solutions for product teams

            Kind Regards,
            Tim

            Tim Eddelbüttel added a comment - Hi Allan, thanks for the update. I'll always appreciate workarounds in general, but workarounds are sometimes solutions for product teams Kind Regards, Tim

            Hi 4e81381d415c,

            The idea of the workaround is to at least have some way to see the apps while there's no fix for this issue.
            As someone from support, my idea was to help our customers in the meantime, so they can know which plugin JARs are present.

            But it turns out that this issue was fixed a couple of weeks ago under JRASERVER-78316.

            This was fixed on the marketplace side, so no update in Jira should be needed. In a quick test, Jira seems to have the old (desired) behavior again.

            Cheers,
            Allan

            Allan Gandelman added a comment - Hi 4e81381d415c , The idea of the workaround is to at least have some way to see the apps while there's no fix for this issue. As someone from support, my idea was to help our customers in the meantime, so they can know which plugin JARs are present. But it turns out that this issue was fixed a couple of weeks ago under JRASERVER-78316 . This was fixed on the marketplace side, so no update in Jira should be needed. In a quick test, Jira seems to have the old (desired) behavior again. Cheers, Allan

            Thanks for adding the reactive workaround but i still would highly prefer that the initial change get reverted to the old behaviour as this is bad by design.

            Maybe an improvement to the workaround itself. Instead of reading the human readable aka. marketing name plugin name (which can contain every character that you don't want as a file name), read the artifactId from pom.xml which is usually also the original filename.
            Additionally you have to restart Jira itself after running the rename.

            Tim Eddelbüttel added a comment - Thanks for adding the reactive workaround but i still would highly prefer that the initial change get reverted to the old behaviour as this is bad by design. Maybe an improvement to the workaround itself. Instead of reading the human readable aka. marketing name plugin name (which can contain every character that you don't want as a file name), read the artifactId from pom.xml which is usually also the original filename. Additionally you have to restart Jira itself after running the rename.

            That's a bug and not a suggestion as this was introduced with the recent upgrades of UPM itself and therefor break the existing functionality.
            If i'm not wrong since the introduction of JRASERVER-77129 the problem exists.

            If i, would same as in JRASERVER-77129 use the argument of security, then this behaviour is bad. I'll agree it's just a name, but the name is an indication

            Tim Eddelbüttel added a comment - That's a bug and not a suggestion as this was introduced with the recent upgrades of UPM itself and therefor break the existing functionality. If i'm not wrong since the introduction of JRASERVER-77129 the problem exists. If i, would same as in JRASERVER-77129 use the argument of security, then this behaviour is bad. I'll agree it's just a name, but the name is an indication

              Unassigned Unassigned
              685a0702ccab Mohit Yadav
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: