Minyaa Suite

How did you process the uninstallation ?

When the uninstallation is done, are you able to find file *.myaa in atlassian-jira folder and subfolder ?
If No, the installation has been sucessfully done,
If Yes, you may restore the original JIRA file as follow for each file.ext.myaa files found :

• delete the file file.ext
• rename the file.ext.myaa as file.ext

The sub-Task access are managed by Minyaa through a Custom Permission and a change in secure/views/issue/viewissue.jsp

When you commented in GHS-1655, that you have the same issue after having removed Minyaa plugin, you was writing about the Issue transition for old issue or any new issue ?

In the database, look in JIRAISSUE table the WORKFLOW_ID field and verify if it exists as Id in OS_WENTRY, it may be a direction to search (It is not verified as linked to Minyaa)

Note that Minyaa 1.3.2 fixes the issue, and that next release of Minyaa (1.4) removes the override of WorkflowManager.
We are interested by your returns.
Regards
Vincent

Hi Vincent,

unfortunately the issue is still unresolved. I was too busy to resolve it at the time, so I reactived Minyaa as a workaround. But now my trial license expired and I'm forced to resolve it, otherwise our Jira instance will remain broken.

I have uninstalled Minyaa as follows:

• at some point after the license expired, Jira showed only a maintenance message saying that Minyaa would have been uninstalled and that a restart would be required. I restarted.
• after the issue reappeared I stopped Jira, removed the Minyaa libraries and restarted

the issue is still persisting...

Regarding your suggestions:

• I could not find any *.myaa files, neither in the jira distribution directory, nor in the jira home directory
• I have checked an example issue with missing subtasks in the DB and it has a jiraaissue.WORKFLOW_ID which is present in OS_WFENTRY

Can you be more specific what I should do in secure/views/issue/viewissue.jsp ?

As the issue is still unresolved I'd appreciate it if you could provide me with another trial key, to work around the issue until we have resolved it. I have sent you a separate email about this.

Regards,
Simon

During installation Minyaa replaces in viewissue.jsp

<jsp:include page="/includes/panels/issue/view_subtaskissues.jsp" />

by

<%-- 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 --%>

During the installation, viewissue.jsp is backuped as viewissue.jsp.myaa, before modification.
And during uninstallation, viewissue.jsp is restored from viewissue.jsp.myaa.

These process may meet issues if the procedures are stopped before the end.

Let me know about the issue resolution

I am not seeing subtask on the main either with Minyaa still installed. I have a support ticket open with Atlassian, but now I suspect it is Minyaa causing this problem.

Update - yes, it was Minyaa. Remove the customization noted above and all is well again.

Vincent, please explain what this customization is doing? I have removed it for now. Is the view subtask permission something Minyaa adds? For future reference, Minyaa should document all customizations like this that are done to help admins (and Atlassian) with issues like this.

Bob,

This customization is done in order to provide a Browse Subtask permission. It is a custom permission provided by Minyaa. It is evaluated if associated Minyaa Settings (secure/admin/plugins/settings/ViewPluginsSettings.jspa) is activated ..
Is the Custom Permission to Browse Sub-Task is evaluated
If True then administrator will have to apply this permission explicitly to authorized users.

I am currently restesting uninstallation procedure to identify why the original viewissue.jsp is not restored.

Have you more details on your configuration, that can help me to identify it ?

Do you want a new issue since my problem is on an installed Minyaa! And I checked the permissions and they are the same as on old installation.

On an installed Minyaa, you have to process as follow :

• If you do not want use the Browse SubTask permission
  • Deactivate the evaludation in Minyaa Settings (secure/admin/plugins/settings/ViewPluginsSettings.jspa)
• If you want use the Browse SubTask permission
  • Activate the evaludation in Minyaa Settings (secure/admin/plugins/settings/ViewPluginsSettings.jspa)
  • Apply permission to want people

Let me know if it is correct.

I don't have a secure/admin/plugins/settings/ViewPluginsSettings.jspa. Was this suppose to be created on Minyaa install? Anything else we may be missing?

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

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,

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.

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