Hi all, I'm sorry about this email being so long but I really looked into this issue just last week and I think there's more to it than meets the eye. In short, I agree with both of you as I have both problems described in your previous emails. * Carlos, indeed the "Before" and "Last" words are not logically usable by a human being to understand just from the GUI what they mean. They need to be rephrased, at the very least. * Michiel, you are 100% correct in saying "I think people are expecting to be able to search for tickets that will reach pending in 1 day" and the catch is that people need this in addition to the current functionality. Warning! Changing the logical meaning of 'Before' and 'Last' will cause some pain for some people. HACK 1 - around the issue noticed by Michiel Reinterpret the meaning of pending time so that it no longer means the time when a ticket should be closed (as it means for states "pending auto close -/+"). Instead, "pending time" will mean the reference moment after which, when a certain time-interval has passed, an event should occur. So then if you need to send out a warning to customers 1 day before a ticket is closed, you should set OTRS pending time 1 day before the desired closing time and work out a ~ complicated set of custom "pending auto" states, generic agent jobs and notifications based on events that together will give you the desired effect. You will need at least two Generic Agent jobs: * GA job1: Filter by "Pending Time" = "before" "1" "minute" AND "State" = "pending auto - wait for warning", then change "State" to "pending auto - wait for close". Meanwhile, an event driven notification was hooked on "Event" = "TicketStateUpdate" AND "State" = "pending auto - wait for close" which will fire ~ 1 day before the ticket is closed and send out those pre-close warnings to customers. * GA job2: Filter by "Pending Time" = "before" "1" "day" AND "State" = "pending auto - wait for close", then change "State" to "closed successfully". The trouble with the above approach is that it's both complicated to understand / setup and, the worst, that it reinterprets the meaning of "pending time" based on the ticket state. This would need to be communicated to both customers and agents, which is always a pain and will always create confusion. HACK 2 - around the issue noticed by Michiel Other people decided the wording "Before" / "Last" is ~ OK and they changed the code so that "Before" means less than X time-interval before pending time. For version 3.1.10, the change would mean replacing - with + on line 1432 from "Kernel\System\TicketSearch.pm": * Line 1432 in v3.1.10: $TimeStamp -= ( $Param{TicketPendingTimeOlderMinutes} * 60 ); This solution may be appropriate for some but it actually creates another problem for others because after this change you can't filter tickets older than X time-interval. You can read about both hacks here: http://forums.otterhub.org/viewtopic.php?f=61&t=15187 and here: http://forums.otterhub.org/viewtopic.php?f=62&t=6843 MAGICAL SOLUTION THAT SOLVES ALL PROBLEMS :) Requirements: - Be able to specify the following filtering conditions for "Pending Time" - Opt.1. Between -infinite and some moment in the past, specified relative to current time (e.g. pending time is older than 5 days/weeks/months/etc.) - Opt.2. Between some moment 1 and some moment 2, both specified relative to current time (e.g. pending time is between 7 and 10 days old OR pending time is between 3 days old and 7 days in the future OR pending time is between 10 and 15 days in the future) - Opt.3. Between some moment in the future, specified relative to current time, and +infinite (e.g. pending time is farther in the future than 10 days/weeks/months/etc.) - Changes in GUI: - Eliminate radio button option "Ticket pending time reached" ... - Add a new radio button option "Ticket pending time older than" [time amount textbox*] [time unit combobox]. This will cover Opt.1. - Add a new radio button option "Ticket pending time between" [time amount textbox*] [time unit combobox] "in the" ["past"|"future" combobox] "and" [time amount textbox*] [time unit combobox] "in the" ["past"|"future" combobox]. This will cover Opt.2. - Add a new radio button option "Ticket pending time farther than" [time amount textbox*] [time unit combobox]. This will cover Opt.3. - Changes in code: - The validation / interpretation of the options from GUI is more complicated BUT ultimately you can still transform the relative values from the GUI into fixed values mapped on TicketPendingTimeNewerMinutes and TicketPendingTimeOlderMinutes. * Why the time amount textbox instead of the current number combobox? Because the way time amount is currently specified, if you need to filter an event that is farther than 60 hours (2.5 days) from pending time, there is no way to specify a filter criteria with finer granularity than 1 day because you need to choose "days", at least, as time units. The problem gets really bad if you need to specify a time unit above days. For example, if I need to filter all tickets that are older than 7 days and warn the customers that they will be closed, I can do that with a delay of max 10 minutes, coming from Generic Agent scheduling. However, I can't simply switch them to state "closed successfully" because I need notifications sent out to customers that the tickets were closed. Thus, I must pass these tickets through one more state "closed successfully, waiting post-close customer notification" of type "pending auto". A notification event would be hooked on this state and my desired notifications would be sent out. Now the problem manifests itself because I can only close these tickets with a job that will run no sooner than the moment when the tickets get older than 8 days, not 7 days and, let's say, 1 hour. This creates problems for ~ real time reports because during the 8th day the state of my auto closed tickets can't be "closed", it will be "pending auto", even though they are logically closed. Phew. /bogdan On Sat, Sep 29, 2012 at 6:15 PM, Michiel Beijen wrote:

Hi Carlos,

You hit a very nice point. Actually my English is also pretty challenged; so I brought up this topic recently when I did a workshop in England to get some native English input.

Generally, the proposal was to use 'more than' and 'less than'. One other key item is the word 'ago', which incidates the past; so if you search for Create Time more than 6 days ago this would be, tickets created more than six day ago, and if you search for create time less than 5 days ago.... well you get the point.

With the Pending time setting, if I understand the issue here the word 'ago' is missing, I think people are expecting to be able to search for tickets that will reach pending in 1 day, but instead they only can search for tickets that have reached pending time more than or less than some time in the past, or 'ago'. So it might be that we would need an extra option, to search 'Pending time reached in less than... or more than... (in the future).

Does this help? -- Mike

On Sat, Sep 29, 2012 at 4:00 PM, Carlos Rodríguez wrote:

...

Hi All,

By trying to fix a Bug I fall in the same trap as reporters for bugs 7047 and 6975 also fall, lets take a look into GenericAgent filter section for any time related field (e.g. Pending Time): Ticket pending time reached "Last" 01 days(s), this is the default setting and if you just see this (and for my poor English knowledge) this means that the pending time was expired in the last 1 day from NOW, in other words 1 day ago.

But wait... there is another option Ticket pending time reached "Before" 01 days(s)….hmm this sounds creasy looks that they are the same: the pending time was expired one day before NOW, in other words 1 day ago.

As a developer I normally don't use this features neither for GenericAgent nor TicketSearch, but I'm sure that there are a lot of experienced consulters and users that does and that understand exactly what "Last" means, but was not my case, so I dig into the SQL statement and I found that the SQL query for "Last" has the following line: AND st.until_time >= 1348876961 (from the context I got this statement it means that until_time is equal or greater from 1 day after NOW)

WOW so "Last" means After…. well that makes sense if you have the 2 options "Before" and "After" that are opposite, so why do we have the options "Before" and "Last" since in most cases they are not opposite?

Do anyone knows any context where "Last" means something in future?

Now look at the ticket search screen, other example ticket crete: Ticket Create Time (before/after): "Last" 01 days(s)… same problem but here we have a bit of light in the label

Lets look at the code, in both cases looks like: if ( $GetParam{ $Type . 'TimePointStart' } eq 'Before' ) { $GetParam{ $Type . 'TimeOlderMinutes' } = $Time; } else { $GetParam{ $Type . 'TimeNewerMinutes' } = $Time; }

Only word "Before" is used and is used correctly…. that is nice and good.

So finally my proposal is to Change the word "Last" to "After" at least in otrs 3.2 but I would like to change it also for 3.1 and maybe for 3.0 (the impart in the code logic is 0, since the value is not used explicitly, only "Before", so the change is only at frontend output parts)

I think this problem exists since otrs 2.4 and maybe before.

This is the root cause of the bugs 7047 and 6975 and maybe others.

What do you think?

((enjoy))

Carlos Rodríguez

_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

---

OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev