Minyaa Suite was born to replace the Kaamelot plugin, a plugin created 5 years ago, when I tried to merge all enhancements brought to JIRA in order to meet our needs.

This first year was mainly spent:

• in dispatching features by theme in dedicated modules
• in integrating different mechanisms
  • to install/uninstall Minyaa with its code intrusions in JIRA
  • to manage licences to access different modules of Minyaa
  • to process background upgrades
• in enhancing existing features in terms of User Interface
  • Workflow Functions (Conditions, Validators and Post),
  • Auto Transition Service,
  • …
• in following all big changes occurred with JIRA 4.x:
  • New Licence Structure based on user limit
  • Migration from Portlet to Atlassian Gadgets
  • New Starter program: 10$ for 10 users
• in extending Minyaa Time’s report with any type of Fields
• in extending Minyaa Workflows with a Workflow Designer able to:
  • provide a graphical way to define your workflows
  • integrate more features provided by OSWorkflow (Common Transitions, Global Transition, Recursive Transition)
• in assisting you in the adoption of Minyaa, which is easier to install than Kaamelot when the procedure is followed, but can be difficult when a step is skipped.

Next year, we will concentrate on the following:

• ERADICATE most intrusions performed by Minyaa, in order to:
  • simplify its installation
  • support the UPM (Universal Plugin Manager)
  • perhaps support JIRA Studio (this will be a challenge!)
  • stop making the Atlassian Support guys crazy about Minyaa
• Continue to enhance Minyaa Workflows’s features (OSWorkflow has again some useful mechanisms)
• Extend Minyaa Time with new features (wait and see!)
• Integrate Myrddin plugin  in Minyaa Projects (Don’t try finding it… It was developed at the same time as Kaamelot, but was never released.)
• And always assist you in the adoption of Minyaa

Happy Birthday Minyaa!

“Align JIRA to your process“ is more than a slogan. It is an objective that we are trying to reach with Minyaa Suite for all our clients.

Since Minyaa 2.0, a new Workflow Designer allows you to create more easily Workflows using a graphical tool and giving the ability to use some unreachable features provided by OSWorkflow, library used by JIRA to manage workflows.

When you open JIRA for the first time, you discover the generic workflow :

• 5 Steps : Open, In Progress, Resolved, Closed and Reopened
• 7 Transitions : Create Issue, Start Progress, Stop Progress, Resolve Issue, Close Issue, Close (Resolved) Issue and Reopen Issue

Using the default Workflow Editor (HTML based), you see them as demonstrated below:

There are 2 Close Issue transitions, but when you try to produce the same Workflow using the default editor, you are not able to create 2 transitions with the same name.
There are 4 transitions reachable from different Steps, but always trying to do the same with default editor, you are not able to reproduce it.

After reading JIRA documentation and different JIRA Community contributions, you will discover that you have to use XML language to reproduce the default JIRA Workflow!

If you open the default JIRA Workflow with Minyaa Workflow Designer, you will obtain the view below:

You will have a better view of existing interactions between the different Steps and Transitions.

Many companies consider JIRA as an inexpensive tool to implement workflow for some of their processes … Fine ! But their processes are not always simple ones, and by using the default JIRA Workflow Editor, some of them may obtain something incomprehensible as showed below:

Edited with the JIRA Default Workflow Editor, this workflow needs more than 5 pages of your Browser ! Even when edited with the Minyaa Workflow editor, this workflow is still too large to be used easily.

This Workflow has 28 Steps and 141 Transitions … an XXL Workflow !

If we take a deeper look inside this Workflow, we will be able to identify some Transitions candidate to be defined as Common Transition or perhaps as Global Transition, and/or qualified as Recursive Transition, but also some exotic practices :

• 20 Cancel Transitions to step Cancelled :
  • 4 allowed to all Users
  • 1 reserved to the Reporter + Screen
  • 1 reserved to the Reporter or Project Roles (10002,10031)
  • 14 reserved to Project Roles (10002,10031)
• 6 Reject Transitions to step Rejected :
  • 1 reserved to the Reporter or Project Roles (10002,10030,10031)
  • 4 reserved to the Reporter or Project Roles (10002,10031)
  • 1 allowed to all users

• 12 Request More Info Transitions
  • 1 reserved to the Reporter or Project Roles (10002,10030,10031)
  • 11 reserved to the Reporter or Project Roles (10000)
    • 6 Transitions to step Deployment – Pending Info
    • 5 Transitions to other different Steps

• 9 Edit Transitions (All recursives)
• 11 Put on Hold Transitions
• 18 Enter Info Transitions
  • 6 Transitions from Pending Info (each of them with a condition to return to previous step), but Pending Info is never reachable (It appears that it was an aborted try!)

  <condition type="class">
     <arg name="jira.previousstatus">Deployment - Upload Verification</arg>
     <arg name="class.name">com.innovalog.jmwe.plugins.conditions.PreviousStatusCondition</arg>
     <arg name="jira.mostRecentStatusOnly">yes</arg>
  </condition>

  • 6 Transitions from Deployment – Pending Info (each of them with a condition in order to return previous step)
  • 6 Transitions from different step, always returning to previous Step
• 4 Activate Transitions
  • 2 Transitions are strictly identical
  • 2 Transitions differs just by a Post-Function
• 13 Reschedule Transitions

As you see, most of these 93 Transitions may be assumed duplicated. When you have to define complex workflow, JIRA allows to create Step Transition only, and not Common Transition.

Editing workflows with XML may allow you to use Common Transition, but in this current example, the associated XML file has more 6000 lines !

Minyaa Workflow allows to declare Common Transitions, Global Transitions and qualify them as Recursive Transition, without using XML syntax.

To be honest, Minyaa Workflow Designer (developed in Flex) has encountered its current limits with this workflow when we tried to refactorize it. We will have to enhance its performance.

But in order to see what this workdlow would be, if it was created directly with the Minyaa Workflow Designer,  its re-factorization has been done manually through XML.

We are obtaining the following Transitions :

• 4 Cancel Transition
• 3 Reject Transition
• 7 Request More Info Transition
• 1 Edit Transition qualified as Recursive Transition
• 1 Put on Hold Transitions
• 1 Enter Info Transition with the Post-Function : Back to Previous Step
• 3 Activate Transitions (potentially only 2)
• 1 Reschedule Transitions

Just by using Common Transition and the Back to Previous Step Post-Function provided by Minyaa Workflows (release 2.1), the workflow has now 60 Transitions (21 Common Transitions) and 22 Steps. It is now a XL Workflow.

The above screenshot is excruciatingly painful to read… From 93 Transitions identified as possible duplication, there are now 21 Common Transitions. Links from Transition to Step have been reduced, but there are still many links from Transition to Step.

With the current workflow, most of the new Common Transition are not in the Nominal Scenario : Cancel, Reject , Request more Info, Enter Info, Edit, Put on Hold. Then, you are able to hide Links from Steps to Transition …

I hope you do not have to design workflow as complex as this one, but I imagine that you do not have time to invest in learning the XML syntax for OSWorkflow library.

Like the default Workflow Editor, with Minyaa Workflow Designer, you will be able to :

1. Clone a Workflow or Create a new one,
2. Create Normal Step and Step Transition
3. Configure all Transition with Condition
4. Validator and Post-functions

Still unable to associate a Screen to your transition!

But also, you will access more features provided by OSWorkflow and be able to :

1. Move Step Transition as Common Transition,
2. Move Common Transition as Global Transsition,
3. Move Global Transition as Common Transition,
4. Detach a Step from a Common Transition,
5. Qualify any Step, Common or Global Transition as Recursive Transition,
6. Link a Step directly to a any Step or Common Transition
7. Link a Step to itself and also create a Recursive Step Transition
8. Have unused Common Transition
9. Use some special Worflow function provided by Minyaa
10. See your workflow in a graphical interface (It is always more easy to present)
11. Also create a Snapshot of your Workflow for documentation …

Download a 30 day Trial for Minyaa now and discover Minyaa Workflow Designer.
You can now design the workflow needed by your business, and  do not let a workflow design your business !

Your feedback is welcome to enhance the Minyaa Workflow Designer capacities.

Useful links to the documentation:

• OSWorkflow by OpenSynphony
• Minyaa Workflow Designer
• Transitions by OSWorkflow
  • Step Transition
  • Common Transitions
  • Global Transitions
  • Recursive Transition
• Post-Function
  • Back to Previous Step

Note : The re-factorization presented above was done using Minyaa 2.1

Minyaa Suite 2.1 is released an available for download

Minyaa is compatible from JIRA 3.13.0 to JIRA 4.1.2 (8 distinct builds).
News since Minyaa Suite 2.0 …

Release Notes :

• Minyaa is now JIRA 4.1.2 compatible,
• Minyaa Workflow Designer features have been enhanced (See details here) :
  • Re-attach a Transition to another Destination Step,
  • Re-attach a Transition to another Originating Step as Recursive Transition,
  • Qualify Step Transition as Common Transition,
  • Qualify Step or Common Transition as Global Transition,
  • Qualify a Global Transition as Common Transition,
  • Create Recursive Transition from a Step,
  • Setup Create and Edit Transitions mapped with Create and Edit Operations (Extended Issue Validation)

  See how to create a Workflow with Minyaa Workflow Designer ...
  

• New Workflow Functions (See details here) :
  • Post-function restoring the Issue to the step previous to the transition,
  • Validator on count of Selected Fix Version or Affected Version,
  • Validator for Fibonacci numbers (depending on Resolutions),
• New Custom Permission to allow or forbid to enter Worklog for past date (See details here).
• and some different bugs fixing … See detailed Release Notes

Download your Trial for Minyaa Suite now …

or ask for your Minyaa Starter License

Minyaa is the successor of Kaamelot plugin, initially developped for JIRA 3.7 and maintained until JIRA 3.12.

When Minyaa started to replace Kaamelot, there were more than 120 modules in atlassian-plugin.xml file.

Kaamelot (now Minyaa) comes with improvements for different features in JIRA and many i18n properties.

Following Atlassian documentation, the way to define i18n properties is as follows :

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
  <module key="ModuleKey" name="ModuleName" ...>
      <resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
   </module>
   <module key="OtherModuleKey" name="OtherModuleName" ...>
      <resource type="i18n" name="i18n" location="com.myplugin.jira.MySecondClass" />
   </module>
</atlassian-plugin>

For some modules, the I18n resources were declared using 2 files, in order to reuse existing i18n resource files without having to duplicate translations.

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
<resource type="i18n" name="i18n.Other" location="com.myplugin.jira.MyOtherClass" />
...
</module>
...
</atlassian-plugin>

Without more detailed documentation, when Kaamelot (Minyaa) required to extend existing i18n properties, the technic used was to append a new I18n Location in the extended WebWork Action, by accessing I18nBean object.
You can imagine that with 120 modules (components, webwork actions, Report, Portlet, Service, Issue Tab Panel, Project Tab Panel, …), extending i18n properties may be a pleasure …

With JIRA 4.0, the Gadgets arrived with new constraints … Minyaa portlets have been migrated into real Gadget (Atlassian Framework 2) only for JIRA 4.1.x.

As Minyaa performs many extensions in JIRA components, it was not possible to migrate Minyaa plugins in OSGi Plugin. Only Portlets have been migrated into Gadget in separate Plugin (jira-plugin-minyaa-xxx-gadgets-4.x.x-x.x.jar).

Gadgets, as any graphical item, require I18n Properties ! How does it work ?

Following Atlassian documentation, it only requires to declare in gadget xml file the supportedLocales macro with a key filter for I18n key. A new component (the I18nResolver) is able to load all I18n resources of all plugins and extend the Gadget definition using the key filter.

Ok, lets go ! For Minyaa Core, my first portlet to migrate was Minyaa Fragment Portlet …

• The Minyaa Core Gadget plugin (jira.plugin.minyaa.core.gadget) is created.

• The declaration is done as follows :

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs ...>
#supportedLocales("gadget.common,portlet.fragments")
</ModulePrefs>
...
</Module>

• All needed i18n resources definitions are provided by the plugin identified jira.plugin.minyaa.core

Oups … Some of i18n key were not translated!

After many search in documentation, I have connected the debugger in order to understand where the issue was …

Root cause :

The I18nResolver performs a scan of all i18n resources provided by different plugins, and jira.plugin.minyaa.core i18n resources are found and loaded!
Yes, but they are loaded in a Container based on HashMap and using the couple pluginKey + i18nName, as a key.

It means that jira.plugin.minyaa.core i18n resources are loaded using jira.plugin.minyaa.core as pluginKey, and each i18n Resources Name.
Since Minyaa Core plugin contains more than 1 module the i18n Resources were not unique.

Before the migration, the atlassian-plugin.xml modules were declared as follows :

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
<resource type="i18n" name="i18nOther" location="com.myplugin.jira.MyOtherClass" />
...
</module>
<module key="OtherModuleKey" name="OtherModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MySecondClass" />
...
</module>
...
</atlassian-plugin>

Since the migration, each i18n resource has to be unique (per i18n resource file) as follows :

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
<resource type="i18n" name="i18nOther" location="com.myplugin.jira.MyOtherClass" />
...
</module>
<module key="OtherModuleKey" name="OtherModuleName" ...>
...
<resource type="i18n" name="i18nSecond" location="com.myplugin.jira.MySecondClass" />
...
</module>
...
</atlassian-plugin>

I18n translation is important for all plugins, but you need to be aware that for large and old plugins, this is not a small work !

Minyaa’s blog is now online!

You will be able to read here :

• all news related to feature available in Minyaa Suite
• some trips and tricks about JIRA plugin developement
• …

Have a good read.