We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.
For more information around feature requests in the Cireson Community click here.
Portal Search Should should understand when the Work Item type changes.
A preferred behavior would be one of following:
- If this is the first search (in that you've just got to the page and built no search criteria/actually searched anything yet), the single criteria of "Search All Work Items by" changes to the Work Item type selected
Outside of this, the search would continue to work as it currently does today
Comments
1) AND/OR logic is not always obvious to everyone
2) The difference between work items is not always obvious to everyone (as much as we would like everyone to understand ITIL )
Barring a full redesign, I would propose just getting rid of this section:
And adding it as a "Work Item Type" property in this section:
Then, that drop-down list could combine all the similar-properties between classes. Many of the same properties are inherited from Work Item, while others are different-but-similar-in-purpose, such as:
- SR Support Group versus Tier Queue versus custom MA/CR Support Groups
- SR Status versus IR Status versus CR Status, etc..
- Classification versus Area, etc..
Most of these are already combined in the ServiceManagement WorkItem table.As a throwback to middle school math, the AND/OR part of this comes down to 'order of operations' and inserting some logical parenthesis ("Add Group" as it is labeled now). If we had the above changes, and an "Add Group/Parenthesis" button at the top-level, and an "Add Filter to Group" button at each group-level I think it would make a bit more sense.
Of course, it could always be improved further with drag/drop, custom properties/enums, etc,... but we gotta start somewhere!