Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'custom fields'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Management
  • Design
  • Requirements
  • Development
  • Test
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-Commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-Commerce
  • Others

Categories

  • Thoughts
  • Debate
  • Health
  • Hobbies

Categories

  • Personligt
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Designs
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Categories

  • Prologue
    • About This Book
  • The Tools
    • Jira Software
    • Confluence
    • Jira Service Management
  • The Inception Phase
    • Portfolio Management
    • Project Management
  • The Design Phase
    • Design as part of the Inception phase
    • Design as part of the Requirement phase
    • Working with design libraries
  • The Requirement Phase
    • Definition of Requirements
    • The four levels of Requirements
  • The Development Phase
    • Atomic design
    • Estimations
  • The Test Phase
    • The Definition of Test
    • Types of Test
  • The Operations Phase
    • Release Management
  • The Post Go-Live Phase
    • Incidents
    • Changes
  • Notes
    • My Muses
    • Research

Categories

  • Theme Building
  • Javascript Framework
  • CSS Framework
  • IPS: Pages
    • Database Templates
    • Block Plugin Templates
    • Page Templates
  • Custom Applications
  • Tips & Tricks

Categories

  • Europe
    • Central Europe
    • Eastern Europe
    • Northern Europe
    • Southeastern Europe
    • Southern Europe
    • Western Europe
  • North America
    • United States of America
    • Canada
    • Mexico
    • Caribbean
    • Central America
  • South America
    • Argentina
    • Bolivia
    • Brazil
    • Chile
    • Colombia
    • Ecuador
    • Falkland Islands
    • Guyana
    • Paraguay
    • Peru
    • Suriname
    • Uruguay
    • Venezuela
  • Africa
    • Northern Africa
    • Central Africa
    • Western Africa
    • Eastern Africa
    • Southern Africa
  • Asia
    • Central Asia
    • East Asia
    • South-Eastern Asia
    • Southern Asia
    • Western Asia
  • Oceania
    • Australia
    • Fiji
    • Kiribati
    • Marshall Islands
    • Micronesia
    • Nauru
    • New Zealand
    • Palau
    • Papua New Guinea
    • Samoa
    • Solomon Islands
    • Tonga
    • Tuvalu
    • Vanuatu

Categories

  • Shared Hosting
  • Virtual Private Server
  • Cloud Hosting
  • Dedicated Hosting
  • Co-Location
  • Hosting Services

Categories

  • Professional
    • Management
    • Design
    • Requirements
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Categories

  • Defects
  • Ideas
  • Development
  • ☑ Archive

Categories

  • Professional
  • Management
    • Agile
  • Requirements
  • Design
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Hosting
  • Atlassian
  • Security
  • E-commerce
    • CRO
    • SEO
  • Interesting

Categories

  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Forums

  • General
    • Open Forum
    • Support
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics
  • Wolcen's Wolcen Topics
  • Quality Assurance Heroes's QA Topics
  • Visual Studio Code's Forum
  • Adobe Illustrator's Adobe Illustrator Forum
  • Sketch Guru's's Sketch Topics
  • Requirements & test management in Jira's Topics
  • Microsoft Teams's Microsoft Teams Discussions
  • Figma's Figma Topics
  • Microsoft Planner's Microsoft Planner Topics
  • Psychology's Psychology Topics
  • Microsoft Word's Microsoft Word Topics
  • Microsoft Powerpoint's Microsoft Powerpoint Topics
  • WordPress Devs's Wordpress Topics
  • Ornamental Design's Ornamental Design Topics
  • Adobe Photoshop's Photoshop Discussions
  • Agile 2's Agile 2 Topics
  • Agile 2's Agile 2 Principles
  • Microsoft Outlook's Outlook Topics
  • My Book's Discussions
  • Outriders's Outriders Discussions

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Invision Power Services
    • JWSE Support Tickets
    • JWSE Task Management
  • Shadownessence's Files
  • WordPress Devs's Wordpress Files

Calendars

  • Project: JWSE Workboard
  • Project: JWSE Workboard
  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events
  • Agile 2's Agile 2 Events

Blogs

  • How to start your own blog
  • Sketch Blog
  • Building The Site's Blog
  • Destiny 2's Destiny 2 ramblings
  • The Journey's Stories
  • Diablo 4's Diablo 4 blog
  • Sketch Guru's's Sketch News
  • Requirements & test management in Jira's News
  • Agile 2's Agile 2 Blog

Categories

  • Personal
    • Humor
    • Music
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
  • Destiny 2's Videos
  • The Journey's Videos
  • Cinephilia's Trailers
  • Diablo 4's Diablo 4 Videos
  • Wolcen's Wolcen Videos
  • Visual Studio Code's Videos
  • Adobe Illustrator's Adobe Illustrator Videos
  • Sketch Guru's's Sketch Videos
  • Requirements & test management in Jira's Videos
  • Microsoft Teams's Microsoft Teams Videos
  • Figma's Figma Videos
  • Microsoft Planner's Microsoft Planner Videos
  • Psychology's Psychology Videos
  • Microsoft Word's Microsoft Word Videos
  • Microsoft Powerpoint's Microsoft Powerpoint Videos
  • WordPress Devs's Wordpress Videos
  • Ornamental Design's Ornamental Design Videos
  • Adobe Photoshop's Photoshop Videos
  • Agile 2's Agile 2 Videos
  • Microsoft Outlook's Outlook Videos
  • Outriders's Outriders Videos

Categories

  • Movies
    • Action Movies
    • Adventure Movies
    • Animated Movies
    • Comedy Movies
    • Crime Movies
    • Drama Movies
    • Fantasy Movies
    • Horror Movies
    • Romance Movies
    • Sci-Fi Movies
    • Thriller Movies
    • Western Movies
  • TV Shows
    • Action TV Shows
    • Adventure TV Shows
    • Animated TV Shows
    • Comedy TV Shows
    • Crime TV Shows
    • Drama TV Shows
    • Fantasy TV Shows
    • Horror TV Shows
    • Romance TV Shows
    • Sci-Fi TV Shows
    • Thriller TV Shows
    • Western TV Shows

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 3 results

  1. In the last article we talked about defining workflows, so now it's time to talk about defining custom fields and screens. The custom fields is where most companies make many mistakes by trying to build new ways for Jira to work and screens almost no one seem to use. Let us change that, but first let us go over what these things are. We start with custom fields. Custom fields explained Custom fields are extensions of the data built in to Jira by default. This allow you to make adjustments to your Jira instance in the event that you need it. Custom fields comes in many pre-defined formats such as date fields, droplists, labels and even cascading select lists. In short you can model the data you work with pretty much any way you want. That is usually also the big problem with custom fields... Custom fields are defined just like most things in Jira using attaching the custom fields to a scheme. For custom fields this is called Field Configuration Schemes. These schemes connect a custom field configuration with the custom fields. This field configuration is what defines how each custom field should be used in a specific context. This allow you to have different behavior and configuration for the same fields. Custom fields - new data objects that extend the database model. Field configuration - Definition of configuration and behavior for custom fields. Field configuration schemes - map fields with field configurations. This is attached to a project to define that projects field configuration. Impact on performance Custom fields have an impact on performance. Period. Anyone who think otherwise do not understand how custom fields work or what impact they have on the system. Jira uses an indexing system that cache data in order to quickly find the relevant data you search for. For this Jira uses Apache Lucene, an open source high-performance, full-featured text search engine library written entirely in Java. Whenever you use a board, filter, dashboard or search in Jira you will use Lucene. Every custom field you add will grow the data exponentially in the index as it will be added to every single issue in Jira, even if that issue does not have any data in the field. Just by adding custom fields you will see an impact on performance and if you are careless about the size of your projects or do not manage your releases properly, then you can render the Jira instance almost unusable dye to loading time. Use custom fields with care! Mandatory fields impact Mandatory fields can be set in the field configuration. This will make a certain field mandatory that you have to fill in. This may sound like a great way to force the users to fill in the data you want them to, but in reality it is causing serious issues, especially when working with any form of integration. When you have integrations that send data to Jira, then do not use mandatory fields, or make sure that it is mandatory for all projects. Having multiple versions of what data is mandatory is a sure way to make integrations fail. This is because we set up a condition that say that unless this data is part of the data you want to submit, it will fail. The most common reason for using mandatory fields is because the teams do not understand why they should fill in the data. This is because of poor education on how the workflow should be done or because the way it is designed makes no sense to the people actually doing the work. This should be solved on a method and process level and not in the tool. Building new systems in Jira with Custom fields The biggest failure I see in Jira is when custom fields are used to extend the capability of Jira to something it is not built for. The most common thing I see is that a story is used as a business need and then kept all the way though deployment. I understand the thought behind it, but the execution will require dozens if not hundreds of new fields and it will just become a mass of data that is almost impossible to work with. Jira is first and foremost a development tool. It starts with a need that has been transformed into a work order for the development team. In many cases you also have test included in Jira. Often as a plugin or just in the workflow itself. That is all Jira should do as there are other tools that should handle business need, requirements as well as build and deployment. In large organizations this behavior is very dangerous. I often see people getting burned out or just give up an aspiration of coherent and logical way of working as the systems evolve to grotesque monsters no one really understand or want. Do not build new ways of working, stick to the standards that exists and you will be much happier. If you are going to extend the capabilities of Jira, then always use a Jira designer that can design the system globally for all users. NEVER allow teams and groups within the organization to design on their own, unless they are an isolated group that never need to work with outer teams or systems. That lead to a fragmented way of working that will cost millions to repair in the future. One field to "always" use Despite all the issues that comes with custom fields there is one field I always think makes sense. There are others of course because in all organizations there are a few fields that makes perfect sense and that really improve the way of working. One such field is "Team", but only if you are not using a plugin like Portfolio for Jira as that already have teams built in. The reason why team is useful in almost any scenario is because it allow you to work across Jira Projects in a standardized setup. This way we can avoid Jira projects with hundreds of people and instead work with boards. Using this field you can assign issues to teams rather than people allow for cross project assignments. We will discuss this more in future articles. Screens and why they matter Where custom fields are abused to the point of absurdity in many organizations, screens are barely used at all in my experience. This is strange as screens are very useful for making sure you are working with the right data at the right time. This will make things much easier when creating new issues or allow you to have certain data filled in during transitions in the workflow. Screens are divided into 3 views: View screen - The view used when you look at an issue i Jira. Edit view - The view showed when you edit the issue. Create View - the view when you create an issue. This allow us to focus the information in creation view for example to make sure that we only see the fields that we actually need, and then have all information in view and edit. When defining screens we have three parts to do so: Screens - Where we define what data should be available in the screen. Screen Schemes - Where we define what screens should be used for the View/Edit/Create views Issue Type Screen Schemes - Where we define what screen schemes should be used for the different issue types. One common use of defining screens is to define the create view for defects. This allow for a more focused defect report process where only the fields we really need is shown when creating the defect. Once created it will allow for all the same fields as a story since it is actually a story that describes a need that has yet to be addressed. Defining fields in a screen So, first we start by defining the screens. First we want to create a new screen for defects so we can define the fields we want when creating new defects. We go to Jira Settings ->Issues -> Screens where we find all our current screens. Then on the top right we can click the button to create a new screen. Add a name and a description and then click add. This will take us to the screen configuration page where we can define the data we want. Since this is a defect we want to capture the problem, where the problem occurred and also who should get the defect to look at. We define the fields like this: Issue Type* - Needed to we can set this as a defect. Reporter* - So we know who reported the defect for follow up. Summary* - The headline that summarize what the problem is. Environment* - Where was the defect found (test, pre-prod, dev and so on). This is needed for defects, but if this had been for production incidents we would not need this field as it is always in production. Affects version* - what code base or release is this related to so we know in what code we should look for it. Description* - This is where the defect is described. It should be steps to reproduce and expected results. Attachments - Pictures or videos that help describe the defect. NEVER upload office files here as you need to download them, which is a horrible way to work. Assignee - Sometimes used to assign a defect to a QA lead for example or a Project manager for attention. Responsible team - When the responsible team in known it can be added to the defect as well. Priority / Severity - How bad the defect is and not how soon it should be fixed. Components - what area of the system the defect affects. Labels - for labeling. Linked issues - If there are other issues that are relevant to the defect. Epic Link - If you use epics to group things. * These fields are mandatory. The rest can vary depending on your work process. It is important that these fields are also available in the default screen. If they are not present there they will not show as we do not have custom screens for the view or edit screens in this example. If you forget to add them, then do not worry. The data will still be there, but it will not show until you have added the fields to the screen. Defining views for Defects With this done our next step is to define the three views for defects so we later can attach it to the right issue type. We do this by going to Jira Settings ->Issues -> Screen Schemes and click on the button saying Add Screen Scheme. Add a name and a description, then set the default screen. This should not be the new screen we created as that one will only be used for the create action. You can change this later if you want. With that in place we come to the configuration page where we assign screens to the three actions we have (Create, View, Edit). By default you have one screen defined for all actions here, which is the one selected when creating the screen scheme. Now we will add our new screen to the create action and we do that by clicking the top right button that says "Associate an issue operation with a screen". Now you can select one of the three actions and a screen. We select the create action and connect that to our new defect screen and click add. Defining screen schemes to defects Now that we have the screen configured we need to add it to the correct issue and to do that we first need to create a issue Type Screen Scheme. We do this by going to Jira Settings ->Issues -> Issue Type Screen Schemes. Again we click the add button in the top right and add a name and description. This time we also can select a default screen scheme so we add the default screen sheme that will be used for all actions rather than the custom field we created for creating new defects. This can be changed later if you want. Once we have this created we get into the configuration screen. Here we will have a default screen scheme set for all issue types. Now we will need to add the new screen scheme we created for defects here. We do that by clicking the button in the top right that says "Associate an issue type with a screen scheme". Select the issue type Defect and then the screen scheme we created earlier and click add. ...and we are done. From now on we will always see the fields we have defined in the Defect screen when we create new defects. We can edit the fields as we see fit and it will not affect any other screens. Since we did not create custom screens for edit or view it means that we will see the same fields as for all other issues once the defect has been created. Focus information when needed As you can see it is not very complicated to add new screens, but they can add quite a bit of focus to your workflow. For this example we created a focused screen for reporting defects, but you will most likely want additional screens. One such screen that I almost always add is the Resolve screen that shows up when you resolve an issue. This is done by adding a trigger in the workflow that add a screen on an action as a popup. We will cover that setup in another post. I hope this was useful for you and in our next article we will discuss Jira security & access. In case you have missed any of the previous articles you can find them all here.
  2. In the last article we talked about defining workflows, so now it's time to talk about defining custom fields and screens. The custom fields is where most companies make many mistakes by trying to build new ways for Jira to work and screens almost no one seem to use. Let us change that, but first let us go over what these things are. We start with custom fields. Custom fields explained Custom fields are extensions of the data built in to Jira by default. This allow you to make adjustments to your Jira instance in the event that you need it. Custom fields comes in many pre-defined formats such as date fields, droplists, labels and even cascading select lists. In short you can model the data you work with pretty much any way you want. That is usually also the big problem with custom fields... Custom fields are defined just like most things in Jira using attaching the custom fields to a scheme. For custom fields this is called Field Configuration Schemes. These schemes connect a custom field configuration with the custom fields. This field configuration is what defines how each custom field should be used in a specific context. This allow you to have different behavior and configuration for the same fields. Custom fields - new data objects that extend the database model. Field configuration - Definition of configuration and behavior for custom fields. Field configuration schemes - map fields with field configurations. This is attached to a project to define that projects field configuration. Impact on performance Custom fields have an impact on performance. Period. Anyone who think otherwise do not understand how custom fields work or what impact they have on the system. Jira uses an indexing system that cache data in order to quickly find the relevant data you search for. For this Jira uses Apache Lucene, an open source high-performance, full-featured text search engine library written entirely in Java. Whenever you use a board, filter, dashboard or search in Jira you will use Lucene. Every custom field you add will grow the data exponentially in the index as it will be added to every single issue in Jira, even if that issue does not have any data in the field. Just by adding custom fields you will see an impact on performance and if you are careless about the size of your projects or do not manage your releases properly, then you can render the Jira instance almost unusable dye to loading time. Use custom fields with care! Mandatory fields impact Mandatory fields can be set in the field configuration. This will make a certain field mandatory that you have to fill in. This may sound like a great way to force the users to fill in the data you want them to, but in reality it is causing serious issues, especially when working with any form of integration. When you have integrations that send data to Jira, then do not use mandatory fields, or make sure that it is mandatory for all projects. Having multiple versions of what data is mandatory is a sure way to make integrations fail. This is because we set up a condition that say that unless this data is part of the data you want to submit, it will fail. The most common reason for using mandatory fields is because the teams do not understand why they should fill in the data. This is because of poor education on how the workflow should be done or because the way it is designed makes no sense to the people actually doing the work. This should be solved on a method and process level and not in the tool. Building new systems in Jira with Custom fields The biggest failure I see in Jira is when custom fields are used to extend the capability of Jira to something it is not built for. The most common thing I see is that a story is used as a business need and then kept all the way though deployment. I understand the thought behind it, but the execution will require dozens if not hundreds of new fields and it will just become a mass of data that is almost impossible to work with. Jira is first and foremost a development tool. It starts with a need that has been transformed into a work order for the development team. In many cases you also have test included in Jira. Often as a plugin or just in the workflow itself. That is all Jira should do as there are other tools that should handle business need, requirements as well as build and deployment. In large organizations this behavior is very dangerous. I often see people getting burned out or just give up an aspiration of coherent and logical way of working as the systems evolve to grotesque monsters no one really understand or want. Do not build new ways of working, stick to the standards that exists and you will be much happier. If you are going to extend the capabilities of Jira, then always use a Jira designer that can design the system globally for all users. NEVER allow teams and groups within the organization to design on their own, unless they are an isolated group that never need to work with outer teams or systems. That lead to a fragmented way of working that will cost millions to repair in the future. One field to "always" use Despite all the issues that comes with custom fields there is one field I always think makes sense. There are others of course because in all organizations there are a few fields that makes perfect sense and that really improve the way of working. One such field is "Team", but only if you are not using a plugin like Portfolio for Jira as that already have teams built in. The reason why team is useful in almost any scenario is because it allow you to work across Jira Projects in a standardized setup. This way we can avoid Jira projects with hundreds of people and instead work with boards. Using this field you can assign issues to teams rather than people allow for cross project assignments. We will discuss this more in future articles. Screens and why they matter Where custom fields are abused to the point of absurdity in many organizations, screens are barely used at all in my experience. This is strange as screens are very useful for making sure you are working with the right data at the right time. This will make things much easier when creating new issues or allow you to have certain data filled in during transitions in the workflow. Screens are divided into 3 views: View screen - The view used when you look at an issue i Jira. Edit view - The view showed when you edit the issue. Create View - the view when you create an issue. This allow us to focus the information in creation view for example to make sure that we only see the fields that we actually need, and then have all information in view and edit. When defining screens we have three parts to do so: Screens - Where we define what data should be available in the screen. Screen Schemes - Where we define what screens should be used for the View/Edit/Create views Issue Type Screen Schemes - Where we define what screen schemes should be used for the different issue types. One common use of defining screens is to define the create view for defects. This allow for a more focused defect report process where only the fields we really need is shown when creating the defect. Once created it will allow for all the same fields as a story since it is actually a story that describes a need that has yet to be addressed. Defining fields in a screen So, first we start by defining the screens. First we want to create a new screen for defects so we can define the fields we want when creating new defects. We go to Jira Settings ->Issues -> Screens where we find all our current screens. Then on the top right we can click the button to create a new screen. Add a name and a description and then click add. This will take us to the screen configuration page where we can define the data we want. Since this is a defect we want to capture the problem, where the problem occurred and also who should get the defect to look at. We define the fields like this: Issue Type* - Needed to we can set this as a defect. Reporter* - So we know who reported the defect for follow up. Summary* - The headline that summarize what the problem is. Environment* - Where was the defect found (test, pre-prod, dev and so on). This is needed for defects, but if this had been for production incidents we would not need this field as it is always in production. Affects version* - what code base or release is this related to so we know in what code we should look for it. Description* - This is where the defect is described. It should be steps to reproduce and expected results. Attachments - Pictures or videos that help describe the defect. NEVER upload office files here as you need to download them, which is a horrible way to work. Assignee - Sometimes used to assign a defect to a QA lead for example or a Project manager for attention. Responsible team - When the responsible team in known it can be added to the defect as well. Priority / Severity - How bad the defect is and not how soon it should be fixed. Components - what area of the system the defect affects. Labels - for labeling. Linked issues - If there are other issues that are relevant to the defect. Epic Link - If you use epics to group things. * These fields are mandatory. The rest can vary depending on your work process. It is important that these fields are also available in the default screen. If they are not present there they will not show as we do not have custom screens for the view or edit screens in this example. If you forget to add them, then do not worry. The data will still be there, but it will not show until you have added the fields to the screen. Defining views for Defects With this done our next step is to define the three views for defects so we later can attach it to the right issue type. We do this by going to Jira Settings ->Issues -> Screen Schemes and click on the button saying Add Screen Scheme. Add a name and a description, then set the default screen. This should not be the new screen we created as that one will only be used for the create action. You can change this later if you want. With that in place we come to the configuration page where we assign screens to the three actions we have (Create, View, Edit). By default you have one screen defined for all actions here, which is the one selected when creating the screen scheme. Now we will add our new screen to the create action and we do that by clicking the top right button that says "Associate an issue operation with a screen". Now you can select one of the three actions and a screen. We select the create action and connect that to our new defect screen and click add. Defining screen schemes to defects Now that we have the screen configured we need to add it to the correct issue and to do that we first need to create a issue Type Screen Scheme. We do this by going to Jira Settings ->Issues -> Issue Type Screen Schemes. Again we click the add button in the top right and add a name and description. This time we also can select a default screen scheme so we add the default screen sheme that will be used for all actions rather than the custom field we created for creating new defects. This can be changed later if you want. Once we have this created we get into the configuration screen. Here we will have a default screen scheme set for all issue types. Now we will need to add the new screen scheme we created for defects here. We do that by clicking the button in the top right that says "Associate an issue type with a screen scheme". Select the issue type Defect and then the screen scheme we created earlier and click add. ...and we are done. From now on we will always see the fields we have defined in the Defect screen when we create new defects. We can edit the fields as we see fit and it will not affect any other screens. Since we did not create custom screens for edit or view it means that we will see the same fields as for all other issues once the defect has been created. Focus information when needed As you can see it is not very complicated to add new screens, but they can add quite a bit of focus to your workflow. For this example we created a focused screen for reporting defects, but you will most likely want additional screens. One such screen that I almost always add is the Resolve screen that shows up when you resolve an issue. This is done by adding a trigger in the workflow that add a screen on an action as a popup. We will cover that setup in another post. I hope this was useful for you and in our next article we will discuss Jira security & access. In case you have missed any of the previous articles you can find them all here. View full blog article
  3. En av de mer irriterande aspekterna av Wordpress är att du är begränsad när det gäller typ av innehåll. Bara jobba med poster eller sidor blir lätt klaustrofobiskt och det brukar bli plugins av olika slag som får utöka detta. Med Pods Framework däremot så kan du enkelt bygga dina egna post typer och taxonomier själv, precis som du vill ha det! Skapa nya post typer och taxonomier är väldigt enkelt, även utan plugins, men om du inte är så van att jobba med kod i functions filen så kan jag varmt rekommendera Pods Framework. Pluginet är väldigt enkelt att jobba med och du kan snabbt sätta upp flera olika post typer. Du kan till och med utöka befintliga post typer och pages med nya attribut om du vill! Det är lite extra trevligt att jag kan utöka funktionaliteten i mitt tema med nya post types och taxonomies för den funktionen är inbyggt. Det jag måste kika på just nu är bara hur jag utökar funktionaliteten med kategorier/taxonomier så jag kan få samma utmärkning som vanliga poster får. Jag undersöker också om jag kan ändra utseendet på arkivsidorna för nu får alla post typer samma utseende vilket inte är helt optimalt. För kategorierna och posterna i sig är det inga problem, de kan jag styra som jag vill genom temats inbyggda inställningar. Just nu känns det väldigt trevligt att jobba med sajten om man säger så! Jag ska testa lite mer med Pods Framework innan jag ger ett slutgiltigt utlåtande. Jag kikar även på några andra, liknande, plugins för att skapa och hantera custom post types och taxonomier, så jag ska skriva om det i framtiden.
×
×
  • Create New...