JSON Viewer and JSON Editor

There are lots of online JSON viewer and I’ve alwasy used this one:
http://jsonviewer.stack.hu/

Today, instead, I’ve needed an editor in order to write a sample JSON for sharing it with a customer.
I tried some editors and this one has won:
http://www.jsoneditoronline.org/

It allows you to design the json using a tree and generate JSON string or viceversa.
In addition you can save it in order to share the url or edit it later.

Very useful!

Pubblicato in REST | Contrassegnato , , , , | Lascia un commento

How does Jira automatically move parent story to done (next status) when all sub issues or tasks are completed? part 2

In my previous post I explained how jira automatically manage the movement of the parent issue.

I analyzed it deeply and here I am with other details.

Before I said that the parent issue must have been in progress in order to allow jira to move it automatically. I didn’t pay attention to default jira behaviour because using the simplified workflow, jira automatically moves it even though the parent issue is in TO DO status.

This made me crazy and I started struggling trying with different workflows and here the result.

What I said in the part1 is the main key:

The parent issue workflow status must be set in the last column, when all subtasks are moved to the last column, Jira checks if the parent issue workflow allows the parent issue to move from the current status to the first status available in the last column of your board.

Here my board configuration:

Here my simple subtask workflow:

Here my previous parent issue workflow that doesn’t allow me to move the parent issue from TO DO to TO DEPLOY, but the parent issue must be set in progress:

Here my new one that allows jira to automatically move the parent issue from TO DO to TO DEPLOY:

Notice the link between TO DO and TO DEPLOY, this is the magic link that leads this behaviour.

Pubblicato in Jira, Management | Contrassegnato , , , , , , | Lascia un commento

MySQL Delete rows subquery You can’t specify target table ‘XXX’ for update in FROM clause

Today my colleague and I have received a gift from MySQL.
Our goal was to delete some rows obtaining them using a subquery.

Here is the query:

DELETE ps_pack FROM ps_pack
WHERE id_product_pack IN (select id_product_item from ps_pack where id_product_pack = 148356904);

And here the response of MySQL
You can't specify target table 'ps_pack' for update in FROM clause

The query is pretty easy but MySQL doesn’t want to delete rows in a table that is used in a subquery.
Looking for a solution we came across a post with the solution (unfortunately I lost the link).

Don’t ask me why but wrapping the query with some useless steps I fooled MySQL:

DELETE  p.* FROM ps_pack p
WHERE p.id_product_pack IN (SELECT  id_product_item FROM (SELECT id_product_item FROM ps_pack where id_product_pack = 148356904) x);
Pubblicato in SQL | Contrassegnato , , | Lascia un commento

Draw chart, network diagram, architectural diagram, gantt etc.

Do you have to write documentation and you need chart or flow diagram, architectural diagram, comunication diagram, gantt or something like that?
If you haven’t installed Visio these sites might help you:

Free (It allows to save your chart directly to an xml file). I like it!
https://www.draw.io/

Free editor (If you want to save you work you need to have an account and pay for it)
https://creately.com
https://www.gliffy.com/

Pubblicato in Uncategorized | Contrassegnato , , , | Lascia un commento

Jira: how to set in progress status when a subtask move to in progress using Script Runner

This is something that Jira would have done by default but it doesn’t…
So If you require that the parent issue change status from TO DO to In Progress when a subtask move from TO DO to In progress, this is the solution.
Buy Script Runner that is cheap and allows you to do whatever you want.
Add a post function (script runner) to the transition of the subtask workflow.
Here is the code to add in the subtask transition post function from TO DO to In Progress

import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.ComponentManager
import com.atlassian.crowd.embedded.api.User
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption

import com.atlassian.jira.util.JiraUtils;
import com.atlassian.jira.workflow.WorkflowTransitionUtil;
import com.atlassian.jira.workflow.WorkflowTransitionUtilImpl;

def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
 
if (issue.isSubTask()) 
{
    def parentIssue = (MutableIssue)issue.getParentObject()
    def currentParentStatus = parentIssue.getStatusId()
    // if the parent has the id of the status TODO (change it with your Jira ID)
    if (currentParentStatus == "10000") 
    {
        WorkflowTransitionUtil workflowTransitionUtil = (WorkflowTransitionUtil) JiraUtils.loadComponent(WorkflowTransitionUtilImpl.class);
    	
    	workflowTransitionUtil.setIssue(parentIssue);
        // 61  is the Id of the transition from TO DO to In Progress
        workflowTransitionUtil.setAction(61);          
        workflowTransitionUtil.validate();
        workflowTransitionUtil.progress();
    }        
}

In order to manage it correctly I suggest adding also the change status from In Progress to TO DO when all subtask moved back to TO DO status.
To achieve this goal add the post function to the subtask transition from In Progress –> TO DO

import java.util.Collection;
import com.atlassian.jira.ComponentManager;
import com.atlassian.jira.config.SubTaskManager;
import com.atlassian.jira.event.issue.AbstractIssueEventListener;
import com.atlassian.jira.event.issue.IssueEvent;
import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.MutableIssue;
import com.atlassian.jira.issue.issuetype.IssueType;
import com.atlassian.jira.util.JiraUtils;
import com.atlassian.jira.workflow.WorkflowTransitionUtil;
import com.atlassian.jira.workflow.WorkflowTransitionUtilImpl;

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption

 
if (issue.isSubTask()) 
{
    def parentIssue = (MutableIssue)issue.getParentObject()
    def currentParentStatus = parentIssue.getStatusId()
    // if the parent is in status in progress
    if (currentParentStatus == "3") 
    {
        def areAllToDo = true;
        def subTaskIssues = (Collection<MutableIssue>) parentIssue.getSubTaskObjects();
        
        // I'll check all subtask's status
        for (MutableIssue subTask : subTaskIssues)
        {
            def subTaskStatusId = subTask.getStatusId();
            
            // even though this is a post function when you check the item's status that triggers this function it's the old one, so it's not updated
            // I'll check that all issues are in TO DO a part from this issue that will'be in In Progress
            if (subTaskStatusId != "10000" && issue.getId() != subTask.getId())
            {   
                areAllToDo = false;
                break;
            }
        }
        
        if (areAllToDo) {
            
            WorkflowTransitionUtil workflowTransitionUtil = (WorkflowTransitionUtil) 
            JiraUtils.loadComponent(WorkflowTransitionUtilImpl.class);

            workflowTransitionUtil.setIssue(parentIssue);
            // 111 is the transition Id from In progress to TO DO (Stop Progress)
            workflowTransitionUtil.setAction(111);              
            workflowTransitionUtil.validate();
            workflowTransitionUtil.progress();
        }
        
    }        
}
Pubblicato in Agile, Jira | Contrassegnato , , , | Lascia un commento

Conference call meeting sharing desktop or webcam

In my daily work I usually use some meeting conference softwares.

Here a software list I tried:

  • Skype
  • Skype for business
  • webex
  • mikogo
  • freeconferece.com (not free)
  • Join.me
  • appear.in

I don’t wont to describe any of them but I’ll report only some problmes that I came across using them.

Skype works without any problems, the only requirement is that you have to have an account and the partecipants must install the client.

Skype for business. It is the new version of lync and I don’t like it too much. The thing that I hate is that you can have a call or a chat with a skype client but you can’t share the screen. Damn! Both of them are Microsoft program so there’s no reason about this behaviour.
The only way to achive it is sharing a skype appointment using outlook, and the generated link will work downloding a browser plugin.

Webex is a cisco software for conference, it works well but it is for compnay only.

mikogo and join.me require to install a client if you are the caller and sometime I was usiung computers without having administrator perssion so without having a way to install the required software.

appear.in
SUPER!
A collegue of mine suggested trying this site and I loved it immediately!
You don’t have to register
You don’t have to install anything (a part from browser plugin).
the only thing you’ve got to do is decide the room’s name and share the link to someone else.
It is free and allows to make a call, to use the webcam or to share the desktop. In addition there’s also an integrated chat to share some notes.
You can lock the room when all partecipants have joined, so no one else can join in during your conference.

It halped me many times 🙂

Pubblicato in Uncategorized | Contrassegnato , , , | Lascia un commento

How to manage a Scrum project and QA (Quality Assurance) / test phase with Jira part 2

In my previous article I wrote about the problems I came across using Jira standard project workflow.
In this post I’ll show you in detail how I solved these problems.
Solution Mixing SCRUM and Kanban (it’s not ScrumBan)
In my opinion Kanban is the right choice to show and manage a flow, SCRUM instead, could be good to deal with some status of our workflow.

Dispite of adding the state To Review / To Test / Ready for QA in the dev board, I obtained a good result using a Kanban board for QA users.

First of all I’ve realized two different workflows:

  1. Story (User story, New Feature, Improvement) Task, Bug
  2. SubTask

Here my project SubTask workflow (easy):
subtaskwf
In this workflow I configured:

  • TO DO –> In Progress: I added the validator: Required fields: Remaining Estimate (If you wan’t that your team estimates duration. Some teams prefer to do it other doesn’t but it’s not required in SCRUM, do what you or team prefer)
  • In progress –> To Deploy: I added the resolve input screen in this transition (in order to ask how much time was spent, if you prefer it, or resolution)
  • In progress –> Resolved: I added a post function Remaining Estimate = 0 (this allows to set remaining 0 because Jira doesn’t set it even though the issue is closed)

If you have Script Runner installed (if you haven’t don’t worry), you can also configure these 2 more steps, to move the parent issue to in progress when a subtask move to in progress

  • TO DO –> In Progress: added a post function using script runner in order to change the status of the parent issue
  • In progress –> TO DO: added a post function using script runner in order to change back the status of the parent issue

Here you can find the script I created for this.

Here is my project Story (User story, New Feature, Improvement) Bug and Task workflow:

As you can see, they are very different and the story workflow has lots of status that I’ll explain when I use it below.
To be hones I cloned this story’s (User story, New Feature, Improvement) workflow and I assigned to cloned one to task and bug.
In this task and bug workflows I set these more things:

  • TO DO –> In Progress: I added the validator: Required fields: Remaining Estimate
  • In progress –> To Deploy: I added the resolve input screen in this transition (in order to ask how much time was spent)
  • In progress –> To Deploy: I added a post function Remaining Estimate = 0 (this allows to set remaining 0 because Jira doesn’t set it even though the issue is closed)

So I created 3 different workflows where 2 have the same logic a part from the things listed above.
For Epic I used “JIRA Workflow (jira)” but use what you prefer, it doesn’t matter.

Here a screenshot about my configuration:

I don’t know if you can understand my idea now, but I hope the next part will clear all your doubts.

SCRUM Dev board:

Before going on with this topic, I suggest looking at Story Point vs Estimated Time and config in Jira

Here the explanation of the only subtask statuses:

  1. To Do:
    Something to do
  2. In Progress
    subtask that are worked by someone
  3. Resolved
    subtask resolved

And that is easy.

Some of them are mapped also for story, bug and task.
Here the explanation of the only Story(User story, New Feature, Improvement) Bug and Task statuses manageable in this board:

  1. To Do:
    Something to do
  2. In Progress
    Something that are worked by someone. In case of story when at least a subtask is in progress.
  3. To Deploy
    The story is completed and committed to GIT (svn, tfs)

In this SCRUM board you can only deal with these statuses.
Noticed that when something is completed by devs doesn’t mean that is ready to be tested because many times they have completed it in their environment but it’s not deployed.
Keep this in mind.

As you can see in the Dev board all status are mapped in the last column. This solve the the “Burn down chart impact (previous post)” because every time an issue is completed, It will “burn” its sorypoint (or time estimate do not use it).
Sprint planning
Before starting the sprint, dev team analyzes the story point of each story and split it in the necessary subtasks. I prefer to estimate each subtask in remaining time, but it’s not necessary. The team can avoid to estimate subtasks if they prefer, the important thing are story points.

Sprint starts
The team starts working the stories moving subtasks from TO DO to In Progress. When they move the first subtask the have to remember to move “in progress” the story as well (I automated it, using Script Runner and I’ll tell you how in next posts).
When all subtasks are completed jira asks to complete the story as well.
The story will be moved to the next available status that is “To Deploy”

This is everything I’ve to do in the scrum board
Easy? yes it is.

Kanban DevOps and QA Board:
This board is thinked for “Operations” that deploy the changes or for only QA team that deploys the changes by theirselves using some deployment tools like jenkins.


  1. To Deploy:
    The story is completed and committed to GIT (svn, tfs)
  2. To Test
    All changes are deployed to an integration/staging environment
  3. In Review
    A QA user is reviewing the story, bug task. Here subtasks are not visible.
  4. Closed
    The story, bug, task respctes UAC
  5. Reopened
    The story, bug, task doesn’t respcte UAC so it’s parked in this status

As soon as a user story, task, bug is done they appear in this Kanban board.
I named this board DevOps and QA because the issues that you can see here are completed by dev but this doesn’t mean that a QA team can already chek them.

When all issies are deployed in staging/integration server they are ready to be checked and in order to tell this to you QA team it’s necessary that Operation team moves the story from the state To Deploy to To Test. The operation team could automate this writing a script that uses jira web services to move automatically issues. This solve the problem “The QA must work in the same dev environment (previous post)

Now all user stories are ready to be checked not directly in checking as the default jira baord. A QA member can move the story/task/bug from To Test to In Review and this means that he/her is checking it and this solves “Concurrency QA people (previous post)“.

If the story passes all UACs the QA member move it from In Review to Closed and this means that the story could be deployed in production.

If the story failed the test, QA user have to move the story from In Review to Reopened. But this will not appear to Dev board. In oreder to notify dev team why the story is failed QA user have to create new issues (usually bug or task), link them to the story failed and plan it for the current sprint (this could be the next sprint of the completion of the user story)

Here the detail of a failed story after the creation of some tasks and bugs
storyparenttaksof

Here the detail of the related bug
bugissubtasksof

Now dev team can see tasks or bugs in the dev SCRUM board and using the link dev can understand wich story is referred to.

When dev team completes tasks and bugs, QA can see them appear in the kanban board ready to be deployed.

Using the link inside the user story, It’s easy to understand if all related bugs are complted or not. In case all bugs and tasks are completed QA team can move the story to Close

I wrote a lot, I know!
I hope this solution may help you to manage your software project even if your company is not a pure SCRUM arganization.

Have you found a better solution?
What’s your experience about it?

Pubblicato in Agile, Jira, Management | Contrassegnato , , , | Lascia un commento