Filter Work Item List by Area [3]

[michaelkleinhenz]

Description

As a user, I want to filter the Work Item list by the Area of the Work Items.

Functional Acceptance Criteria

1. The user can filter Work Item lists by Area value.
2. The filter stacks (logical AND) with other, already available filters (like "assigned to me").
3. The filter can be applied to any Work Item list in the main area, like Iterations, Type-filtered lists, Backlog, etc.

Non-functional Acceptance Criteria

None.

Related

1. Userstory Display and Update Area Field on Work Item Detail View [4] #913.

Related Tasks

• UX: UX for the work item list filtered by area. FOLLOW UP: Filter Work Item List by Area fabric8-ux#203
• PLANNER: Display Area as available filter with available areas as options Display Area as available filter with available areas as options #1147
• CORE: Backend to support filter work items by Area Platform/Core : Rest Service for Area fabric8-services/fabric8-wit#648
• PLANNER: Write a service to filter the work item list using filter area=value Write a service to filter the work item list using filter area=value #1031
• PLANNER: Use the service to integrate the filtered list into UI Use the service to integrate the filtered list into UI #1032
• PLANNER: Display selected area filter in active filter list Display selected area filter in active filter list #1033
• PLANNER: Write Mock data for filter WI list by area Write Mock data for filter WI list by area #1034
• PLANNER: Write Functional tests for Filter WI list by area Write Functional tests for Filter WI list by area #1035

[michaelvirgil]

@michaelkleinhenz Michael, can you clarify? My understanding was that the navigation model effectively was the action that resulted in the filtering areas. Are you suggesting something else? The story implies a specific user action on a filter of WIs associated to an area vs. navigation to an area.... thanks.

[ldimaggi]

Can you clarify how the filter stacking will work, and how it will be presented to the user? Will they be able to select multiple filters from a (TBD) consolidated menu? Or will they select multiple filters from discrete pulldowns in the UI? Thx!

[maxandersen]

My understanding was that the navigation model effectively was the action that resulted in the filtering areas.

Don't we already have filtering based on the left menu ? when you click on Iteration it should only show things related to that Iteration ?

[Mgranfie]

Areas are another grouping mechanism in the matrix. it sits above iterations and is assigned via the WI and once defined, yes sits in the navigational path.

…

On Wed, Feb 8, 2017 at 7:07 AM, Max Rydahl Andersen < ***@***.***> wrote: My understanding was that the navigation model effectively was the action that resulted in the filtering areas. Don't we already have filtering based on the left menu ? when you click on Iteration it should only show things related to that Iteration ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#914 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARTwqzdzSq6bnWBsksJfvqD__IWA3g5Pks5rabAHgaJpZM4L5nEP> .

[pmuir]

• Question: What happens when the filter is applied to the backlog? How is it made clear to the user that this is now a filtered view of the backlog?

@michaelkleinhenz Michael, can you clarify? My understanding was that the navigation model effectively was the action that resulted in the filtering areas. Are you suggesting something else? The story implies a specific user action on a filter of WIs associated to an area vs. navigation to an area.... thanks.

You cannot navigate to an area. Areas are filters. @michaelkleinhenz is working on a URL structure proposal that I will validate, which will clarify what appears in the URL path vs the URL query string. We have agreed a starting principal that navigations appear in the path of the URL whilst filters appear in the query string (this is common web practice for 20 odd years).

My understanding was that the navigation model effectively was the action that resulted in the filtering areas.
Don't we already have filtering based on the left menu ? when you click on Iteration it should only show things related to that Iteration ?

This is an interesting question - is clicking in the left menu applying a filter, or navigating. The current UX suggests to me it's a navigation. This means you can navigate to an iteration. This would imply that an iteration can appear in the path of the URL, but I don't want to prejudge the scheme that Michael K is working on.

Areas are another grouping mechanism in the matrix. it sits above
iterations and is assigned via the WI and once defined, yes sits in the
navigational path.

This is not correct. You cannot navigate to an area, it is a filter, which means that the area does not appear in the URL path but in the URL query string.

Areas do allow you to group, but it is not a strong grouping mechanism like a space, rather it is a weak grouping mechansim which can be easily changed.

[Mgranfie]

Thanks for the info Pete. One outstanding point that I find curious is not navigating to the Area and instead using a filter. If I mostly live in one area for work, this means I always have to keep that filter "on"... ?

…

On Thu, Feb 9, 2017 at 12:19 AM, Pete Muir ***@***.***> wrote: - Question: What happens when the filter is applied to the backlog? How is it made clear to the user that this is now a filtered view of the backlog? @michaelkleinhenz <https://github.com/michaelkleinhenz> Michael, can you clarify? My understanding was that the navigation model effectively was the action that resulted in the filtering areas. Are you suggesting something else? The story implies a specific user action on a filter of WIs associated to an area vs. navigation to an area.... thanks. You cannot navigate to an area. Areas are filters. @michaelkleinhenz <https://github.com/michaelkleinhenz> is working on a URL structure proposal that I will validate, which will clarify what appears in the URL path vs the URL query string. We have agreed a starting principal that navigations appear in the path of the URL whilst filters appear in the query string (this is common web practice for 20 odd years). My understanding was that the navigation model effectively was the action that resulted in the filtering areas. Don't we already have filtering based on the left menu ? when you click on Iteration it should only show things related to that Iteration ? This is an interesting question - is clicking in the left menu applying a filter, or navigating. The current UX suggests to me it's a navigation. This means you can navigate to an iteration. This would imply that an iteration can appear in the path of the URL, but I don't want to prejudge the scheme that Michael K is working on. Areas are another grouping mechanism in the matrix. it sits above iterations and is assigned via the WI and once defined, yes sits in the navigational path. This is not correct. You cannot navigate to an area, it is a filter, which means that the area does not appear in the URL path but in the URL query string. Areas do allow you to group, but it is not a strong grouping mechanism like a space, rather it is a weak grouping mechansim which can be easily changed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#914 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARTwqyhaHLKMlD5LdnHWVTnoK0zoAAwbks5raqHhgaJpZM4L5nEP> .

[pmuir]

Thanks for the info Pete. One outstanding point that I find curious is not
navigating to the Area and instead using a filter. If I mostly live in one
area for work, this means I always have to keep that filter "on"... ?

We can certainly look at navigating to areas, as this could well be a useful feature, however it is not part of the MVP.

Regarding 'keeping the filter on' - yes, filters should be persistent between use of the planner, so you can easily keep them on. We should keep the users enabled filters in the profile service or similar.

Filters should also be bookmarkable, appearing in the query string of the URL, so you can keep them on by creating a bookmark.

[debloper]

• Fetching available filters isn't part of this story (please ignore)
• Functional tests and mock data are to be worked on
• UX pending, implemented as default filter UX