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:
Project A
– Objectives
– Tasks
Project B
– Objectives
– Tasks
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.
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
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.
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.
Project A
| Epics
| Features
| User Stories
| Tasks
Project B
| Epics
| Features
| User Stories
| Tasks
Or would the folder selection process be one of the two following cases perhaps:
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.
