nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issues not associated with kanban board - Jira Cloud

Pauline McMilla

I have setup a project and a Kanban board and have been adding issues and working through them no problem. Another team has now setup a project and a sprint board and we want to configure different fields for default screens etc

So, I have set up a field configuration scheme, associated it with my project and also added issue types to my field configuration as per the JIRA knowledge base. Then I reindex. All my current issues (all tasks) on the Kanban board disappear. If I disassociate the issue types with the board, then the issues come back on the board but it also makes my default screens go back to using the default field configuration scheme. If I create a new task then when I create it is says Issue has been created but its not visible on the board - it does not show on the Kanban board with the other issues

I have adjusted the Project filters so that it is for that project but I can't seem to be able to get the right fields to show on my default screens with the field configuration scheme.

board filter2.png

Accepted answers

Nic Brough -Adaptavist-

It may be easier to split this into two parts.

First, you talk about field configuration and issue types. This functionality is about field visibility and behaviour. It has nothing to do with boards (well, it can, in certain cases, but we'll come back to that)

Secondly, the boards. You seem to be making changes and associations that do not really make a lot of sense in JIRA-speak, so I'm struggling to understand what is really happening.

To keep it simple, there are three things that an issue has to do to be shown on a Kanban board

The user must be able to see the issue (i.e. be in a role or group that grants "browse" to them in the project, and match any issue security rules if you're using that function).
The issue must match the board filter
The issue must match the Kanban sub-filter (this is pretty much saying "hide released issues")

You can see that there is no mention of field configurations there. They have nothing to say about whether issues appear on the board or not. Unless you start constructing board filters that do things like "select by content of field that is hidden by a field config", the fields have no impact on visibility.

For a typical Kanban board, you usually keep it quite simple and have:

Everything visible to the user
Project = XYZ
Hide issues where fixversion is a released version

So, I would pick an issue to test with and look at how it matches the board set up.

If you're not sure, then post your board filter and sub-filter here and we can tell you what they mean (and if they may be affected by the field configs)

All comments

Nic Brough -Adaptavist-

It may be easier to split this into two parts.

The user must be able to see the issue (i.e. be in a role or group that grants "browse" to them in the project, and match any issue security rules if you're using that function).
The issue must match the board filter
The issue must match the Kanban sub-filter (this is pretty much saying "hide released issues")

For a typical Kanban board, you usually keep it quite simple and have:

Everything visible to the user
Project = XYZ
Hide issues where fixversion is a released version

So, I would pick an issue to test with and look at how it matches the board set up.

If you're not sure, then post your board filter and sub-filter here and we can tell you what they mean (and if they may be affected by the field configs)

Pauline McMilla

Thanks for getting back to me so quickly. I have managed to solve some of the problems myself but I give you the details you require but also tell you what we are trying to achieve now.

In regards to what you say should be on a typical Kanban Board - we have met all these criteria

Everything visible to the user - YES
Project = XYZ - YES
Hide issues where fixversion is a released version - YES

Attached is the board configuration for your reference.board filter.png

So having resolved a few issues I want to try and explain what I am trying to do.

I have two projects in my JIRA instance.

Project 1 (name ref: ISB)

Project 2 (name ref: DOP)

Each have their own Kanban Board. We have the same users for both boards.

For Project 1, we only have tasks and for Project 2 we have stories and tasks.

For Project 1, when I create a task I want to have a default issue screen that has certain fields. For Project 2, I want to have different default issue screens for stories and tasks. Reading the JIRA documentation, it says this is done by creating different Field Configuration Scheme, 'add the issue type with a Field Configuration scheme' and 'assigning the fields to the default issue screen' etc. I have done all the above and it shows the right fields in the screens for the right project, HOWEVER when I then look at my Kanban Board for Project 1 for example, all the tasks I had created previously they are no longer there. The only way I can make the issue reappear is by not 'adding the issue type with a Field Configuration scheme'. But then the default issue screen for my project defualts back to the Default Field Configuraiton scheme.

So if I am doing this incorrectly please let me know what I should be doing to achieve my requirement of having different default issue screen that has different fields for each Project.

thanks

Pauline

PS and yes, I have also created Issue type screen schemes for each project and assigned them accordingly.

board filter.png

Nic Brough -Adaptavist-

I wish all my support type work read my "more information" questions and gave such clear answers!

Your board config screenshot shows that you've got a simple, clear and pretty much ideal setup for the ISB Kanban board. But I get a bit lost when I get to the "HOWEVER" in the middle of the big paragraph.

It's my reading, not your writing, I think, so I'm afraid I need to ask more questions:

Would it be correct to say that the set up for the DOP board is the same as ISB, except that it looks at the DOP project and selects for "stories" as well as "standardissuetypes" and "tasks"?

In the ISB project, is a "task" a sub-task type, or a parent type? I ask because you've included it in the filter deliberately, alongside the "standardaissuetypes", which suggests that it is a sub-task type (because the standardissuetypes would select it if it were a parent)

You say you have used the field config stuff, and screens to make your issues have the fields you want on them, and I think that means that when you use "create" or "edit", you get the fields you want and expect. My question here is "what do you change to make all the tasks disappear from the board"? Imagine you are looking at the board and the tasks are there. Then you do something. Then you go back and they are gone. What is the "something"?

I'm not at all sure about how you make he issue reappear either - you've said "not adding the...", but that's not an action that changes something, it's not doing something, so something else doesn't happen. I think I've lost myself in that sentence, but I also think it will be answered by the question above.

The baseline thing for me is that the the fields you have on an issue should have nothing to do with the board selections. A board gets a list of issues that match filters. An issue uses some fields. There's no connection between the select and the fields (certainly not in your setup anyway, as you've got simple clear and sensible filters)

Pauline McMilla

Thanks Nic!

Given I work in an IT/Digital team, I understand the need to be as clear as possible with these things. The issues I am having are painful and I can't work them out and its hard to write it all down to make sense of them, so thanks for the encouragement and thanks for understanding. I know we will get there.

OK, to answer your questions

Would it be correct to say that the set up for the DOP board is the same as ISB, except that it looks at the DOP project and selects for "stories" as well as "standardissuetypes" and "tasks"?

yes, the setup is the same but we have tasks and stories on the DOP board, and only tasks on the ISB board. The "standardissuetypes' that you got from my screenshots is me just choose 'standardissuetypes' and then 'tasks' over the option with subtasks. I didn't want subtasks to appear on the board at all. Just in addition, for your information, I have not created a field configuration scheme for DOP at all - it is still using the Default Field Config Scheme for now.

In the ISB project, is a "task" a sub-task type, or a parent type? I ask because you've included it in the filter deliberately, alongside the "standardaissuetypes", which suggests that it is a sub-task type (because the standardissuetypes would select it if it were a parent)

task is a parent type not a sub-task type. When i go to the filter screen I thought I had to choose 'standard issue types' over 'those with subtasks' so I have unticked this now and just selected 'task'.

board filter2.png

You say you have used the field config stuff, and screens to make your issues have the fields you want on them, and I think that means that when you use "create" or "edit", you get the fields you want and expect. My question here is "what do you change to make all the tasks disappear from the board"? Imagine you are looking at the board and the tasks are there. Then you do something. Then you go back and they are gone. What is the "something"?

ok so I followed the instructions here: https://confluence.atlassian.com/adminjiracloud/associating-field-behavior-with-issue-types-776636450.html
When I do the step: "Associating an issue type with a field configuration", I select Task of course, all my issues disappear from the board.
These issues were created over the last few weeks so maybe I need to remap them or something???

Pauline

Nic Brough -Adaptavist-

Ok, great, I wanted to check the filters to see if there was cleverness with sub-tasks, but your tasks are all parent level, so it's nothing to do with that.

To simplify further, let's ignore the DOP board for now and concentrate on the ISB one. It was very useful for comparison and getting a good idea of what you've set up, but I don't think it can tell us much more at this point.

I'm going to make another assumption here too: to get your issues back on the board, you undo the field configuration change and put it back the way it was before.

I'd like to look closely into the field configs next if that's ok? This is hard to explain in prose, so I'm going to define a simple example and hope it's close enough to your setup that we can refer to it and point out what's changing.

Let's say you have a field configuration scheme called "ISB fcs" and it's associated with the ISB project. Let's say that this is quite simple and says

For bugs, use the field configuration called "ISB Bug fc"
For features, use the field configuration called "ISB Feature fc"
By default, for all other issue types, use the field configuration called "ISB default fc"

At this point, your tasks all appear ok on your board.

So, you go to admin and add a new field configuration called "ISB tasks fc"

You then go to "ISB fcs" and add

For tasks, use the field configuration called "ISB tasks fc"

Now you go back to the board and all the tasks are gone. When you go back and remove that line from the scheme, the tasks reappear.

Is that what is happening here?

If it is, could you do three things next:

Apply the scheme so the tasks disapppear, then go to project admin and find the "reindex project" button and click it (if you have tens of thousands of issues in there, you may want to wait for a quiet time of the day, as it'll churn a bit). Then re-test the board
If that does not help, could you compare the two field configurations. In my straw-man above, that would be "ISB default fc" and "ISB tasks fc". Where do they differ?
Can you test what happens if the two field configurations are identical (barring their names)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud