Opened 5 weeks ago
Last modified 5 days ago
#7935 accepted defect (bug)
Core Trac Workflow Keywords Issue
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Trac | Keywords: | needs-patch |
Cc: |
Description
This affects all tracs, but more specifically Core one
There a 4 keywords that have conflicting names:
needs-testing
andneeds-testing-info
has-design
andhas-design-feedback
Where is the problem?
Searches in the Custom Query are made whith a "contains" query filter. This means that searches are not based on exact matches. This means that if you search for either needs-testing
or has-design
you will receive results with needs-testing
, needs-testing-info
or the two. Same for has-design
with has-design-feedback
Solution
Simply modify this two keywords a little bit
For example, instead of:
needs-testing-info
=> needs-test-info
or needs-info-tesing
and
has-design-feedback
=> has-feedback-design
The first one, the needs-testing one is specially important because both are conflicting and render queries of very poor quality.
Change History (9)
This ticket was mentioned in Slack in #core-test by sirlouen. View the logs.
4 weeks ago
#3
in reply to:
↑ 2
@
3 weeks ago
Replying to dd32:
perhaps the solution is to use existing built reports rather than freeform queries.
This needs to be discussed in #core and a direction formalised before any action can be taken on this ticket though.
The problem with this, is that it doesn't provide the opportunity to check for certain types of tickets around needs-testing
which happens to be a "key" keyword. For example, I was willing recently to review tickets that had both needs-testing
and needs-testing-info
at the same time specifically and was completely impossible.
In fact, I have to admit to you that this happens to be the most critical combination of keywords. The other one, I put as an example, was just another case of this inconvenience, but not as problematic as these two.
There are 2 solutions from my perspective:
- Repairing the Trac query system, either by adding exact matches with quotes or the liking, or by just considering each exact keyword for each match between spaces
- The simplest one that requires less coding: renaming either needs-testing or needs-testing info to avoid having them contained in each other. Just a little change like
need-testing-info
will also do the trick and I feel that I will not be less human-readable.
This ticket was mentioned in Slack in #core by sirlouen. View the logs.
3 weeks ago
This ticket was mentioned in Slack in #core-test by sirlouen. View the logs.
6 days ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
5 days ago
This ticket was mentioned in Slack in #core-test by pavanpatil1. View the logs.
5 days ago
#8
@
5 days ago
@dd32 After discussion in a few dev chats, this seems like a good change to make to support the workflows our test team uses to triage tickets, since the existing Trac query filters don't allow for showing needs-testing
without also showing needs-testing-info
.
It looks like both needs-testing-info
and has-testing-info
were added in https://meta.trac.wordpress.org/ticket/5634.
We'd like to see these two custom keywords adjusted to the following:
needs-testing-info
=>needs-test-info
has-testing-info
=>has-test-info
needs-testing
=> No change.
Once these changes are made for the workflow keywords list and the associated JS that was added in https://meta.trac.wordpress.org/changeset/12154 to automatically remove keywords when others are added, I can handle transitioning any existing uses of the previous keywords on open tickets to the new versions (unless that's an easy thing to handle on your side).
P.S. Let's not change the design related keywords for now.
Changing these to be less human readable isn't an ideal solution, I believe some of the reports have something akin to
keywords LIKE needs-testing and keywords NOT LIKE needs-testing-info
- perhaps the solution is to use existing built reports rather than freeform queries.This needs to be discussed in #core and a direction formalised before any action can be taken on this ticket though.