Opened 10 years ago
Last modified 10 years ago
#168 assigned defect
graph start/end times don't reset between single result archive searches
Reported by: | ramonb | Owned by: | ramonb |
---|---|---|---|
Priority: | normal | Milestone: | 1.2 |
Component: | web | Version: | 1.1 |
Keywords: | Cc: | ||
Estimated Number of Hours: | 8 | ||
Description
If you first search a specific job in archive:
- id = something
While in search results, you alter the query, still the same graph start/end times are used
Change History (5)
comment:1 Changed 10 years ago by ramonb
- Owner changed from somebody to ramonb
- Status changed from new to assigned
comment:2 Changed 10 years ago by ramonb
- Summary changed from graph start/end times don't reset between multiple archive searches to graph start/end times don't reset between single result archive searches
actually no: this only happens when performing multiple single result queries after one another.
this is because the limits of the previous job are still set when viewing the new job.
This is semi-by-design due to the fact the time period start/stop is directly passed, for the purpose of allowing a user to modify it.
The easiest solution is to disable the job id input field when viewing single result queries, forcing the user to go back before altering the query.
comment:3 Changed 10 years ago by ramonb
When you only disable the job id input field, all other fields effectively become useless because you are stuck in the 1 job.
another approach could be to completely disable the search form, when viewing single job results. Have to think about it a bit, not sure what's best.
comment:4 Changed 10 years ago by ramonb
- Milestone set to 1.2
- Version changed from 1.0 to 1.1
comment:5 Changed 10 years ago by ramonb
- Estimated Number of Hours set to 8
This happens when going from a search query with 1 job result, to modifying the query such that it has multiple results.
Then the graph/job start/stop times from the 1st query's jobid are retained throughout the rest of the queries.