When creating a BLI or defect from a request, we lose the original attachments, discussions, links and so on from the original request.
This is very painful in that users have to trace back a BLI to the original request to get an example report output attachment, for example.
We should be given the option to carry forward these types of relationships to the new BLI or defect.
by: Robert W. | over a year ago | Product Planning
Comments
An approach to fulfilling the same need (access to the information), is to have access to have direct access to attachments, links and discussions on related upstream items: a backlog item could see this information on related requests, a split backlog item would continue to provide access to the information on the original, etc. One strong objection to copying all these is that future updates would not necessarily be made available: new discussion notes or attachments added to a request today would not be available on a story that was generated yesterday. Taking the 'visibility' approach instead of the 'copying' approach would still give the same access, but without the potential drawbacks of missing the more recent material. Are there any objections you can think of to approaching it in this way?
please to be making this happen. this is death.
I agree, a 'reference' approach would be optimal. Please, "Make it so, number one."
Ideally, if an asset is created from another asset, they should have ONE set of attachments, one set of discussions, and so forth. This includes for a Split story card, as well as for making an asset of one type from another asset. If you add a new comment to the one, you see it for both.
Is there any reason that would NOT be a good idea?
However, using 'copy' to clone an asset should NOT keep a common pool of these items, as we really are making a copy, not making a related item.
Which suggests that maybe being able to 'split' more than just a Story Card may be a good thing. If you 'split' a task, a test, a request, an issue, whatever, then the attachments and discussions are shared between the two. Just a thought...
This change is sorely needed to support a workflow where a person in "Requestor" role can request that we address a defect, and attach a test file.
I would be fine with either copying the attachments or just referencing them. In our workflow, we would close the request as soon as it is converted to a defect, and expect the person in Requestor role to "watch" that defect... So if you take the "referencing" approach, we want it to be able to "reference" a closed request.
I agree with Robert above; however, if the optimal usage is to reference the request, then the "Additional Details" icons should indicate if the reference request has the indicated items--attachment, discussion, notes, etc.
Related: When doing a split. Discussion and links are copied but the attachments are not. This is inconsistent. Improving the rich text editing of the description field (images) would reduce some of the needs for attachments.
The following issue is related:
• I create a regression test for a project via Product Planning / Regression Tests, also adding an attachment in the attachments tab (to use as a screenshot to assist in the eventual execution of the test).
• I then go to Release Planning / Regression Planning, and allocate this Regression Test to a Regression Suite.
• I then generate a regression test set for an iteration from the Regression Suite which includes my regression test
• I then wish to run the test for the iteration by opening up the test via Iteration Tracking/Testboard. However, the attachment is missing ie it has not been carried over from the original regression test template only the Details tab has been carried over.
Regression test sets within an iteration should be based on the regression test suite at the time of creation, and the description, attachment, links should be based on the snapshot at that time as and when the test set was created for the iteration concerned. If a test from the original suite then is altered, then this should not affect any previous tests run (eg for older iterations) because the functionality may have changed and so it is correct that the template has changed but that old tests should not have description/attachments/links updated as a result. This is in fact the way it works now for descriptions.
Would it be possible to make this condition optional. There are several conditions parameters that are userdefinable. Could this be one of them, IE when splitting backlog items include attachments, refference attachments, ignore attachments.
My specific pain is with test cases. We attach test documents to test cases in sprint, I would like to keep the test documents when converting test cases to regression tests.
I agree this is something that could be overwhelmingly useful--especially when you have an Epic that contains multiple Backlogs over multiple Sprints. That way if there is an update to an attachment, all Backlogs would see the update. We have this problem today--an attachment is updated on the Epic and the children don't get the update so developers work with the wrong attachment.
I would like this feature. I provide links to defect tracking items, and email attachments to original Request objects to provide additional context for reference when discussing later with technical leads in order to understand if there is enough info available yet from which to create a backlog item story. I don't want to paste that all into the description log, nor have to rebuild it in the story object. I agree References would keep database bloat down as opposed to copies. You could also provide timestamped lists of attachments/links in the Request object if you wanted to inversely see later attachments to child stories from the perspective of the original request but that would be messy and unnecessary, plus the requester can always just walk the tree of the stories to get more insight.
Would love this....
We were just discussing this very thing the other day. As it stands, I have been working through a process where any needed discussions get continued and the split item gets tagged. This way, we don't lose the vital conversations relevant to the item.
Please add to issues as well.
Would be nice if a parent item would show all attachments for it's children.
+1 for this request.
Just started using Requests for our internal sales people to use, which almost always need attachments to clarify the details.....NEED to have visibility to these accessible from generated Stories!! This item has been discussed for over a year....any plans?
This would be a huge time savings and avoid a lot of confusion when the attachment is not explicitly moved in the current process.
Maintaining Links to attachments within the flow would be very valuable. I.E. Request to Epic, Request to Backlog Item, etc.
Carrying links to attachments forward would be very useful. We are currently stressing the need to utilize Requests to groom work intake.
Here is our use case:
When our Technical Support team logs a problem being reported by customers, we have them create a request. These requests are reviewed by QA, Dev and Product Management. All teams (including Support) exchange vital data via the request, usually consisting of conversations and attachments (e.g.: screenshots and logs.)
When we decide that the request needs to be converted to a defect, we lose all attachments and conversations. It becomes extremely time-consuming for Product Management to have to replicate all of this information, and confusing to Development because the natural flow of the conversation in context is lost.
This is a real time-killer for us...
Hi,
Anyone knows if there was any progress made on this issue?
The management of attachments is somehow very limited when it comes to converting from Requests to Backlog Items in V1, not to mention the splitting of items where the attachments .
Our use case is related to additional documentation or troubleshooting steps that are attached to the V1 Request and copying them over would be a time consuming process.
Referencing the attachments on the Backlog Item should also be fine, as long as all details are available in the backlog item itself.
Thank you.
Please, Please, Please help with this. It might seem insignificant, but when every request has discussion and multiple attachments, IT IS KILLING ME!!! And it leaves a huge gaping hole where tons of error can occur, if someone is not totally focused and hyper-detailed in saving all of this information somewhere, then loading it back into the backlog item once it is created. In an are where there are one or two requests, it's a big enough deal. But when there are dozens, it is incredibly burdensome. My whole job now is downloading attachments and saving comments, and then uploading them to backlog items.
To V1 Team,
There are multiple details that do not carry over from the Requests when Converting them to Backlog assets, one being the Reproduction Steps.
If V1 team cannot create a predefined flow that suites all needs, why not providing options to configure what fields get mapped to each asset type, to allow each team define their own fields mappings for conversion.
Such options would be extremely useful for many organizations that use V1 and the Requests Queue as a landing place for all feedback, before committing to the items in the backlog.
How many votes would take to boost the priority of this idea and do we get V1 commitments to implement it if it get enough votes?
Thank you.
Is this anywhere close to getting done? We really need it.