[FE]: Search for new parent behaviour is not consistent

[AdamPiotrowski91]

Description: (details of what and how should work) "Search" on the level of Object is different than on the level of Multiple Objects. If possible, should be configurable

Additional Context & Ad Hoc Info: To be SPIKEd to understand the needs more

[AdamPiotrowski91]

Unfortunately, there is no easy or direct way to apply any behaviour change with pure webscrapping and any more complex API approach is not planned currently.

Closing as WILL NOT FIX

[AdamPiotrowski91]

With RVI 3.0 Rally API non-GET requests will be implemented as core part of an engine.

This ER will therefore become possible to at least review.

[AdamPiotrowski91]

May benefit from #39 . I'll take more of a "here's the ID of new parent, I know it exists, yes, I am sure I know what I'm doing" approach

[AdamPiotrowski91]

Will be considered covered by implementation of #55 (specifically changing item's properties via command line)

Documentation Example will be provided

[AdamPiotrowski91]

Is resolved via Terminal

command itself is dependent on whether we add feature, new parent user story or we set defect's user story, but all of the workflows can be done via Terminal.

[AdamPiotrowski91]

Final commands to use to cover case:

// ONE
macro ReparentOne "if %1 { grep -f US -i } { cd -x & patch Parent=%2 } { cd -x & patch Requirement=%2 }" -a 2 -d "Reparent US or DE under another US: `call ReparentOne <US-to-reparent> <new-parent-US>`"

// SELECTED
macro ReparentSelected "dom ID Select=true | xargs call ReparentOne %1" -a 1 -d "Reparent selected USs and DEs under new US (requires that you are on a Rally subpage where you have a table of data with selected rows): `call ReparentSelected <new-parent-us>`"

[AdamPiotrowski91]

Macro tested, provided and validated