I think it would be useful to be able to restrict the list of options available for a “parent” type field to a specific folder (or one of x folders). This would be helpful for project based workflows with distinct objectives which you want to parent to all tasks. With the way things are currently, if you have two projects defined like the following:
Then setting the parent of one of the tasks correctly can be a bit difficult for 2 main reasons: The objectives folders have the same name, and the objectives themselves can be similar in nature (with the same title)
I’m not tied to this folder structure, so let me know if there is a better workaround.
I’m not sure what exactly do you mean, and this statement ‘list of options for “parent” type field to a specific folder’.
Is it regarding attributes? I believe that’s the case…
If there’s any room for a video or an image, I’d really appreciate that! Sorry for all the hassle.
So I created a minimal example of what I was talking about
So in this board we have 2 ongoing projects that are structured the same. Below are the objectives for both:
Project A / Tasks is set up with a “reference” attribute named parent. In this example, we are assuming all tasks must have a parent objective from the same project, however there is no easy way to achieve that. In you are looking for “Project A Objective 1” then there are no problems as it is uniquely named
but it is difficult to deal with tasks which share both task and folder names like the following:
It would be nice to be able to restrict which folders are allowed to be referenced from the attribute’s settings
In that example, ideally you would be able to restrict the “parent” reference attribute in Project A / Tasks to only be allowed to reference items from Project A / Objectives, but I believe a multi select restriction would be more universally applicable.
Tank you so much!
I completely understand what are you talking about.
This is really a unique use case… Okay, let me try with this suggestion.
At the end of the ‘item name’ you’re searching in reference field, you can add /[folder name] and eliminate the search result which shows all the items from all the folders.
We’re planning to improve reference UI and first search from a folder from which the desired item is, and then show only items from that folder.
@coa The /[folder name] doesn’t handle the example I gave earlier as the folder names are the same.
For some additional context here, the Objectives / Tasks parity is a simple example. If were to fully implement something more involved such as scrum (Epics > Features > User Stories > Tasks) then it becomes more important to be able to restrict folder options. For example, many projects may end up with an Epic named “User management” or similar.
The reason I chose to split objectives and tasks into different folders (and why I would do the same thing for scrum If i decided to set it up) is because these types of work items are inherently unique with different attribute sets.
When I started going down this path, it was under the assumption that folders per type was “the way” to handle these types of scenarios so I’m a little surprised that you haven’t run into similar scenarios in the past.
To make sure I am on the same page, your future plan is to list folders -> pick one -> list items -> pick one? Wouldn’t that run into the same problem if folder names are the same? i.e.
| User Stories
| User Stories
Or would the folder selection process be one of the two following cases perhaps:
followed by a second choice
Project A / Epics
Project B / Epics
I’ve just run into similar problem where the same name of a subfolder makes it vague what kind of data is going to be affected:
I wanted to delete an unneeded attribute and the dialog warns me that a folder called Podzadania (Subtasks) also contain that attribute. Since I’ve got two such subfolders I don’t know which one the app is referring to.