Always 50+ work items related to build pipeline
Hello, We have a repo with a main and development branch. From the development branch we create feature branches. When we create a PR from feature to development there must be linked at least one work item. But if the build is running (automaticly after approve and close PR) there are always 50+ work items related to the build. I searched for settings but can't find anything. What is wrong here? Please advice. Thanks you!
Create Work Items without Sprint/Iteration
Hi everyone, I have just started using DevOps and have what I am sure is an incredibly basic question but it's confusing me. I want to create a bunch of backlog items that we will develop at whatever point from now into the future. How (if at all) can I create these without it automatically assigning them in to an iteration / sprint (in this case the first sprint as I am setting up for a new project). When I've used Jira, I could create items such as user stories, bugs, tasks etc, in my Product Backlog and they would just sit there in my own priority order (which often changes), until I schedule them in to the next sprint during sprint planning. I may create 5, 10 or 200, but they'll just sit ready for me to do something with them. Nothing gets automatically assigned which is how I want it (for it not to do anything). Currently in DevOps, they appear to automatically get assigned to the next sprint. I'm sure I'm missing something obvious. If anyone can point out my blind spot, that would be great! Thanks in advance.
Limit access to work items (based on tag or similar)
I need to restrict access to all work items in a project, based on a tag or a field - is that possible? As in: due to compliance restrictions certain users may only see work items with a specific tag, nothing else really (at least not something with screen dumps and descriptions in it) Alternatively: is there a way where I can place these users in a separate project and let them view (maybe edit) only these specific work items (without doing double administration, having to maintain them in both projects)
