Forum GLPI-Project

dcumbow

Member

Registered: 2010-11-01

Posts: 9

0.78 Date Range in Ticket Tracking

Hey Folks:

Short and sweet...

In version 0.72.4 that we currently use, you can click the "Advanced" button in the upper right corner of the search criteria when tracking tickets to enter dates for a date range on Open, Closed or Modified date.  With 0.78 the search criteria options have changed.  I love the advanced logic abilities, but I can't figure out how to get a date range (say 1 Oct 2010 to 15 Oct 2010 or 12 Aug 2010 to 19 Oct 2010) for the dates in the ticket.  I've looked at the query that it runs and it sets the SQL criteria to "where date like (%dateInfoHere%)". 

I've busted my brain but can't think of a solution.  Maybe I'm following the wrong path.  Any help you can give would be greatly appreciated.

Cheers,
David

remi

GLPI-DEV

From: Champagne

Registered: 2007-04-28

Posts: 7,127

Website

Re: 0.78 Date Range in Ticket Tracking

Try with 2 criteria
Date "contains" >2010-10-01
Date "contains" <2010-10-15

+

---

Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/

dcumbow

Member

Registered: 2010-11-01

Posts: 9

Re: 0.78 Date Range in Ticket Tracking

Works like a charm!..

Maybe adding a "between" option in the operator selection and providing two dates might be a good enhancement for the next version.  Just a thought.  Where should I submit enhancement requests?

Thanks, remi!

Cheers,
David

sean.tapscott

Member

Registered: 2010-06-16

Posts: 303

Re: 0.78 Date Range in Ticket Tracking

What benefit would be provided by a "Between" option?  Just as easy to name the beginning of the range and the end of the range.

---

Now using 0.78.1 on CentOS.

dcumbow

Member

Registered: 2010-11-01

Posts: 9

Re: 0.78 Date Range in Ticket Tracking

Major reason is that for the average end user that wants to sort through their tickets (and for some of our techs :-/) the method described above isn't very intuitive.  Granted all it will take is some training, but the old interface was easier to understand.

I guess I was thinking more along the line of it being nice to have the datetime that is stored converted to just a date and using between to have the dates be inclusive.  I know you can use >= or <=, but the fact that the criteria on the query handles them as datetime (which is understandable if you want to pull information from a time of day) means that your upper bound cannot be inclusive unless you specify a time with your date.

Just my 2 cents.

Anyways, thank you for your input and assistance in clearing up my issue.

Cheers,
David

sean.tapscott

Member

Registered: 2010-06-16

Posts: 303

Re: 0.78 Date Range in Ticket Tracking

Interesting, thanks for the info, Dcumbow. 

I like to ask these questions because its difficult to imagine all of the ways that GLPI might be used and sometimes I learn something new.  Now I'll have to edit my reporting methodology slightly.

Really think that the >2010-10-18 AND <2010-10-26 would mean from October 18th at midnight to October 26th at midnight?  Why wouldn't it include all of October 26th?  I guess if it was in the datetime format, it would be midnight if not specified.

---

Now using 0.78.1 on CentOS.

dcumbow

Member

Registered: 2010-11-01

Posts: 9

Re: 0.78 Date Range in Ticket Tracking

I feel your pain.  It's impossible to imagine all the use cases that are out there.

I believe the issue lies with the upper bound querying 2010-10-26 as a date because MySQL looks at it as 2010-10-26 00:00:00.  This is less then any other hour during the 26th of October. 

For example:
2010-10-26 12:30:00 < 2010-10-26 evaluates to FALSE
2010-10-25 23:59:59 < 2010-10-26 evaluates to TRUE
2010-10-26 00:00:01 < 2010-10-26 evaluates to FALSE

Feel free to correct me if I'm wrong and let me know if I can assist in any other way.

Cheers,
David