Lesson 4 July 24th 2023

Lesson 4 Summary - AI Meeting Notes + Home Work


We have covered the following topics:

Course Plan Adjustment: The speaker informs the attendees that they will not be receiving homework and instead, they will have a full workshop. They also mention combining some items from the Jira admin course for better learning. The speaker emphasizes making the learning experience interactive and encourages attendees to ask questions.

Workflow Transitions: The speaker explains how transitions work in workflows and how they can be unique or reused if multiple statuses are going through that destination status. They also re-visit triggers, conditions, validators, and post-functions in workflows.

Resolutions Customization: Attendees learn about resolutions in Jira tickets and their importance as reasons why an issue has been closed. The speaker shows them how to customize resolutions by changing names or setting defaults for certain options.

Importance of being careful with deletion permissions in cloud: It was emphasized that there is no backup available in the cloud, so it's crucial to be cautious when dealing with deletion permissions. The recommendation was to use resolution and closing an issue instead of deleting it. Changing the project key can trigger a background reindex, which may cause some issues to be unavailable for a few moments.

Understanding Project Details: The meeting covered various aspects related to project details such as project name, key, URL, type and category. It was explained how each field works and what its purpose is. For instance, the project lead can be changed based on who should take care of the workflow or assigned issues.

Components in Jira Basics Training Course: Components were introduced as essential parts of projects that help categorize them based on logic followed by companies or engineering teams. They allow assigning component leads responsible for specific components within a team.

Case Study - Workflow Modifications Requested by PM: A case study presented a request from a Project Manager (PM) who wanted modifications made to their existing workflow consisting of statuses such as "to do," "in progress," "on hold," "review QA ready for production" and "dump." The team agreed upon making changes that would make their workflow more seamless and easier to work with.

Creating a New Workflow: The team is creating a new workflow to make changes without restrictions. They are using inactive workflows that are not in use or have not been assigned to any project yet. They create statuses such as "To Do," "In Progress," "On Hold," "Review," "QA” “Ready for production" and "Done." It is important to be careful about the capitalization of status names, and once created, it cannot be modified.

Assigning Issues Automatically: The team wants issues that move from any status to in-progress status automatically assigned to the person who made the transition. To achieve this, they add post functions on transitions and choose an 'assign issue' post-function which assigns an issue automatically to the current user making the transition. Jira decides on its own where this action should take place based on scheduling logic but can also be adjusted if needed.

Post Functions: The meeting discussed various post functions available in Jira, including assigning an issue to a reporter, clearing field values based on logic, copying values from other fields (useful for subtasks), and updating the resolution field. The team also talked about how to associate screens with transitions and make certain fields mandatory using validators.

Reopening Issues: The team discussed creating a new transition specifically for reopening issues that have been marked as "Done." They decided to use the clear field value post function to remove the resolution from these issues when they are reopened. This will allow users to add a new resolution type when closing the issue again.

Screen Creation: In order to associate screens with transitions, the team needed to create custom screens first. They created a new screen called "Resolution" which included the Resolution field and Comment section.

Mandatory Fields: To make certain fields mandatory before allowing users to perform specific actions or transitions, validators can be used in Jira workflows. During this meeting, they added a validator requiring that Resolution be filled out before moving an issue from Done status back into To Do status.

Blank Workflow Creation: The team discussed creating a new workflow for the project and encountered some issues with it. They had to create a blank workflow and add necessary post functions to it. They also copied an inactive workflow and made changes to it.

Mandatory Reason Field: The team talked about adding a mandatory reason field whenever someone moves an issue to the “On Hold” column. They created a custom field called "Reason" which is mandatory, so that they don't forget why they moved the issue on hold.

Associating Screen with Transition: The team discussed associating their screen with the transition in order to make sure that their custom fields are visible during transitions. They added their view or screen as properties of transition details, making sure that all fields are properly configured.

Adding Workflow Scheme: The team added existing workflows from Jira system into their project's workflow scheme folder where different workflows for different issue types will be collected in one place and stored under the particular project. This allows them to easily manage multiple workflows for different types of issues within one project folder.

Workflow Configuration: The meeting discussed the process of replacing an existing workflow with a new one and assigning it to all issues. The participants were shown how to add a workflow for a particular issue type and publish it. They also learned how to associate statuses that have been changed, verify statuses, and map them to the current board.

Issue Resolution: Another topic discussed was configuring issue resolution when moving an item into Done status. Participants were shown how to make sure that the resolution field is mandatory, leave comments, and ensure that there is a strike-through on resolved items.

Homework Assignments: Towards the end of the meeting, homework assignments were given out based on workflows and board configurations. Participants were asked to go through case study part two on their own time as well as complete additional homework based on workflows and board configuration.

Recap & Conclusion: A brief recap was done at the beginning of next session for half an hour followed by concluding discussions about issue types in relation with workflows. Participants were encouraged to ask any questions they had regarding these topics or anything else related during this time period.


Homework 2 (Fairly easy): 

  1. Check your keyboard shortcuts. To access the keyboard shortcuts, go to "?" on the top right panel; or find documentation in the Lesson 4 slides.

  2. Create 1 Kanban & 1 Scrum Boards

  3. Create 3 components in all of your projects:
    Backend
    Frontend
    QA

  4. Create 2 Releases (versions/FixVersions) in each project

  5. Create 3 Epics in each project and group issues under those epics (if you don't have any issues, please create 2-3) 

  6. Sort your boards according to epics (through swimlanes) 

  7. Flag 2 issues

  8. Bulk change all issues and add a label: jira_class




Rating
0 0

There are no comments for now.

to be the first to leave a comment.

Additional Resources
Join this Course to access resources