Uploaded image for project: 'Minyaa Suite'
  1. Minyaa Suite
  2. MYAA-437

After removing Minyaa plugin from Jira 4, I cannot see subtasks in the details of the parent issue

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 1.3.2
    • Done
    • Minyaa Suite
    • Security Level: Public
    • None
    • 4.0.0

    Description

      Based on http://jira.atlassian.com/browse/GHS-1655 I uninstalled the minyaa plugin from Jira 4.0. This resulted in the side effect that subtasks section is not shown anymore for any ticket.

      Adding the minyaa plugin again removed the problem. What is the proper way of removing the Minyaa plugin, leaving the base Jira system unaffected?

      Regards,
      Simon

      Attachments

        Issue Links

          Activity

            I mentionned the URL (ie. http://localhost:8080/secure/admin/plugins/settings/ViewPluginsSettings.jspa.) or menu Plugins / Settings in Administration page.

            vthoule Vincent Thoulé added a comment - I mentionned the URL (ie. http://localhost:8080/secure/admin/plugins/settings/ViewPluginsSettings.jspa .) or menu Plugins / Settings in Administration page.

            Hi Bob, Simon,

            The root cause is identified.
            Minyaa performs differents changes in Jira JSP.

            Some of them are done just by adding an jsp:include tag ...

            • In includes/admin/project/summary.jsp
              <%-- Begin MODIFICATION by Minyaa Core --%>\
              <%-- Schemes provided by Plugins --%>\
              <jsp:include page="/includes/panels/project/plugin.schemes.jsp" />\
              <%-- End MODIFICATION by Minyaa Core --%>\
              </page:applyDecorator>
              
            • In secure/views/issue/viewissue.jsp
              <%-- Begin MODIFICATION by Minyaa Core --%>\
              <webwork:if test="hasPermissionToSeeSubTask() == true">\
              	<jsp:include page="/includes/panels/issue/view_subtaskissues.jsp" />\
              </webwork:if>\
              <%-- End MODIFICATION by Minyaa Core --%>
              

            When Minyaa restore JSP by the initial JSP, the file is let unchanged, and Tomcat checks that JSP update date is lower that the compiled date.
            Even if the JSP is restored, Tomcat assumes JSP as unchanged, and do not recompile it. The compiled version try to include the added Minyaa JSP file and then fails.

            A similar issue may ossurs on any modified JSP.

            Short term solution :

            • remove folder <TomcatDir>\work\Catalina\localhost_\org\apache\jsp

            Mean Term solution

            • Perform a touch on restored files in oder to force Tomcat to recompile.

            Regards
            Vincent

            vthoule Vincent Thoulé added a comment - Hi Bob, Simon, The root cause is identified. Minyaa performs differents changes in Jira JSP. Some of them are done just by adding an jsp:include tag ... In includes/admin/project/summary.jsp <%-- Begin MODIFICATION by Minyaa Core --%> \ <%-- Schemes provided by Plugins --%> \ <jsp:include page= "/includes/panels/project/plugin.schemes.jsp" /> \ <%-- End MODIFICATION by Minyaa Core --%> \ </page:applyDecorator> In secure/views/issue/viewissue.jsp <%-- Begin MODIFICATION by Minyaa Core --%> \ <webwork:if test= "hasPermissionToSeeSubTask() == true" > \ <jsp:include page= "/includes/panels/issue/view_subtaskissues.jsp" /> \ </webwork:if> \ <%-- End MODIFICATION by Minyaa Core --%> When Minyaa restore JSP by the initial JSP, the file is let unchanged, and Tomcat checks that JSP update date is lower that the compiled date. Even if the JSP is restored, Tomcat assumes JSP as unchanged, and do not recompile it. The compiled version try to include the added Minyaa JSP file and then fails. A similar issue may ossurs on any modified JSP. Short term solution : remove folder <TomcatDir>\work\Catalina\localhost_\org\apache\jsp Mean Term solution Perform a touch on restored files in oder to force Tomcat to recompile. Regards Vincent
            bob.swift Bob Swift added a comment - - edited

            Vincent, I don't this is the problem I have.

            1. I updated the configuration to turn on the setting to use the subtask permission - this did not help. Also, on migration, I would have expected this to be set to act like Kaamelot.
            2. I modified the JSP to <webwork:if test="hasPermissionToSeeSubTask() != false"> - I believe this is a safer way to perform the check in case there are problems with hasPermissionToSeeSubTask. This work (subtasks now show) but I suspect that the permission setting is still being missed

            Update: confirmed that permission setting is still being missed. Removed permissions and subtasks still show.

            bob.swift Bob Swift added a comment - - edited Vincent, I don't this is the problem I have. I updated the configuration to turn on the setting to use the subtask permission - this did not help. Also, on migration, I would have expected this to be set to act like Kaamelot. I modified the JSP to <webwork:if test="hasPermissionToSeeSubTask() != false"> - I believe this is a safer way to perform the check in case there are problems with hasPermissionToSeeSubTask . This work (subtasks now show) but I suspect that the permission setting is still being missed Update: confirmed that permission setting is still being missed. Removed permissions and subtasks still show.

            Bob,

            I agree with the proposal for <webwork:if test="hasPermissionToSeeSubTask() != false"> !

            Why do you think that you suspect that the permission setting is still being missed ?

            Does the remove of Tomcat work folder (or other J2EE Server?) as I proposed, resolves the issue (waiting for MYAA-464 resolution) ?

            May you bring details on your update ... Does the settings Is the Custom Permission to Browse Sub-Task is evaluated is explicitely (Save of settings has been done at least one time) :

            • enabled
            • disabled

            You may check jira property value in OSProperty tables for key jira.option.BROWSE_TASK.permission.enabled !

            With my lastest tests against Minyaa 1.4, I do not yet encountered trouble, except the Tomcat Cache.

            vthoule Vincent Thoulé added a comment - Bob, I agree with the proposal for <webwork:if test="hasPermissionToSeeSubTask() != false"> ! Why do you think that you suspect that the permission setting is still being missed ? Does the remove of Tomcat work folder (or other J2EE Server?) as I proposed, resolves the issue (waiting for MYAA-464 resolution) ? May you bring details on your update ... Does the settings Is the Custom Permission to Browse Sub-Task is evaluated is explicitely (Save of settings has been done at least one time) : enabled disabled You may check jira property value in OSProperty tables for key jira.option.BROWSE_TASK.permission.enabled ! With my lastest tests against Minyaa 1.4, I do not yet encountered trouble, except the Tomcat Cache.
            bob.swift Bob Swift added a comment -
            1. Testing of a person not authorized to view subtask shows subtasks
            2. I removed the work folder you mentioned - no difference
            3. Setting for Is the Custom Permission to Browse Sub-Task is evaluated has been saved a couple of times
            4. Evaluated select * from propertyentry where property_key like 'jira.option.BROWSE_TASK.permission.enabled%' and found one row with value 1
            bob.swift Bob Swift added a comment - Testing of a person not authorized to view subtask shows subtasks I removed the work folder you mentioned - no difference Setting for Is the Custom Permission to Browse Sub-Task is evaluated has been saved a couple of times Evaluated select * from propertyentry where property_key like 'jira.option.BROWSE_TASK.permission.enabled%' and found one row with value 1

            People

              vthoule Vincent Thoulé
              simons SImon Stemplinger
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: