Add Work Item Association by Id [13] [13] [13] [5] #307
Comments
|
Just to confirm, is the user able to enter link multiple internal work items to a work item? Will any problems result if a user cross links two work items to each other? Or if they inadvertently link a work item to itself? |
|
@ldimaggi updated the story :-) |
|
Note: the crosslinking could require a big effort or a breaking up of this story. |
|
To clarify: the item links are not classified by their meaning ("blocks", "related to", "duplicate", etc.)? |
michaelkleinhenz
changed the title
|
Do we need UX readily available to commence this work? Especially I am in interested in the REST API part. |
|
@baijum I would say yes. We all can kinda imagine how this might look on a technical level, but until UX has done their magic and we've done an iteration with them to verify it's technically possible, then let's retain from going deep into any given technical solution. We don't want to limit what the UX can do because we implemented 'something' already. Or redo what we've done because it doesn't match UX. |
|
Ok, I will watch this: fabric8-ui/fabric8-planner#69 |
|
@michaelkleinhenz I am not following how #307 + #308 are different and fabric8-ui/fabric8-planner#69... |
|
UX is here: fabric8-ui/fabric8-ux#3 |
|
@Mgranfie fabric8-ui/fabric8-planner#69 is the old system, #308 is currently in unknown draft state, see #308 (comment) |
michaelkleinhenz
changed the title
|
@michaelkleinhenz I am creating a story for this in the UX teams JIRA. Would you say that this accurately captures the request? As a user of the ALM tool, I should be able to establish a relationship to another work item, via a URL. I want to clarify that we are not including any qualifiers for the links. For example: "is dependent on", "is related to", "is blocked by", or are these included? Please let me know if these are part of the requirements. |
@michaelkleinhenz @Mgranfie Given @aslakknutsen 's comment I think, that types are included in the links. |
|
@kwk @Mgranfie @aslakknutsen on the qualifiers for links: I would suggest not changing the story that's in progress on the sprint with a new feature that might have a big impact. So for now, the story only requires links with a default qualifier. If the team can achieve more, that's fine but I would not inject a new "must have" requirement with unknown impact into a running sprint. Everything else is the decision of the implementing team. |
|
@michaelkleinhenz #306 States they should be viewed as a list of ID, Title and Type. And the UX for this also show a Type both on view and Add. |
|
Hi Michael, I agree that scaling back is a good thing. How the design adjusts back to Can you tell me what is meant by "links with a default qualifier"? This way Thanks, On Thu, Oct 6, 2016 at 6:15 AM, Aslak Knutsen notifications@github.com
|
michaelkleinhenz
changed the title
Why: Allow users to search using keywords, by passing id:ID_VALUE and URL. What: Currently, only WorkItem linking is the target for the search. * Support search by ID. * Support search by Free Text. * Support search by URL. When a token in the search string is found to be a URL, it is mapped with existing URL patterns in the system [only WI as of now]. input URL is matched and parsed against compiled regex. ID is taken out from URL and postfixed with :* to make startswith() Usage: ./bin/alm-cli show search --q "Test WI" -H localhost:8080 --pp ./bin/alm-cli show search --q "id:1001" -H localhost:8080 --pp ./bin/alm-cli show search --q "http%3A%2F%2Fdemo.almighty.io%2Fdetail%2F3" -H localhost:8080 ./bin/alm-cli show search --q "demo.almighty.io%2Fdetail%2F3" -H localhost:8080 Fixes #330 Fixes #380 Fixes #381 Fixes #382 Fixes #383 Related #307
michaelkleinhenz
changed the title
michaelkleinhenz
assigned kwk and harrybabu and unassigned michaelkleinhenz and harrybabu
michaelkleinhenz
changed the title
This change will introduce the endpoint `/api/workitems/:ID/relationships/links` for work item links that lives under the work item endpoint and automatically filters work item links associated with the work item on the backend. You can also use this endpoint as you would use the `/api/workitemlinks/` endpoint. Also, this change will introduce the `included` top-level JSONAPI element for responses of `/api/workitemlinks/` that return work item links or arrays of work item links. Currently this `included` element will contain only objects of type work item link type. Currently the UI has to do the filtering of links on a particular work item. This should be no longer needed. == Checks In the WorkItemRelationshipsLinksController we perform the following checks for the listed actions. === Create action * We check that the current work item (:id) does exist. * Check that the source ID of the link is the same as the current work item ID (:id). * If no source is specified we pre-fill the source field of the payload with the current work item ID from the URL. This is for convenience. === Delete action * We check that the work item (:linkid) does exist. * Check that the source ID of the link to be deleted is the same as the current work item ID (:id). === List action * No checks are done === Show action * We check that the work item (:linkid) does exist. * Check that the source ID or target ID of the link to be shown is the same as the current work item ID (:id). === Update action * We check that the work item (:linkid) does exist. * Check that the source ID of the link to be updated is the same as the current work item ID (:id). * Check that the source ID of the update payload is the same as the current work item ID (:id). See also fabric8-services#307
This change will introduce the endpoint `/api/workitems/:ID/relationships/links` for work item links that lives under the work item endpoint and automatically filters work item links associated with the work item on the backend. You can also use this endpoint as you would use the `/api/workitemlinks/` endpoint. Also, this change will introduce the `included` top-level JSONAPI element for responses of `/api/workitemlinks/` that return work item links or arrays of work item links. Currently this `included` element will contain only objects of type work item link type. Currently the UI has to do the filtering of links on a particular work item. This should be no longer needed. == Checks In the WorkItemRelationshipsLinksController we perform the following checks for the listed actions. === Create action * We check that the current work item (:id) does exist. * Check that the source ID of the link is the same as the current work item ID (:id). * If no source is specified we pre-fill the source field of the payload with the current work item ID from the URL. This is for convenience. === Delete action * We check that the work item (:linkid) does exist. * Check that the source ID of the link to be deleted is the same as the current work item ID (:id). === List action * No checks are done === Show action * We check that the work item (:linkid) does exist. * Check that the source ID or target ID of the link to be shown is the same as the current work item ID (:id). === Update action * We check that the work item (:linkid) does exist. * Check that the source ID of the link to be updated is the same as the current work item ID (:id). * Check that the source ID of the update payload is the same as the current work item ID (:id). Related to #307
Reference: 1608E102/1608E063
Description
As a user, I want to associate other work items in the system with a work item on the work item detail view.
Functional Acceptance Criteria
It is not possible to associate work items to themselves.(Todd, Max and I discussed that we implement a "network" topology first and that doesn't have these restrictions.)Non-functional Acceptance Criteria
None.
Dependencies
Tasks
The text was updated successfully, but these errors were encountered: