I would not say having "updated"="created" set at issue creation is incorrect, it is a question of how you see things :)
There can be other queries where I want to see the recent issue activity, I will query "updated today" and get also the issue created, which is what I want.
That said, querying the issue not updated yet should be possible, maybe the query engine can allow having filter like "updated_on" = "created" implemented some way ?
--------------------------------------------------------------------------------
I agree that it is not necessarily incorrect to have "update time = creation time". The gap is that the query feature has the option of selecting "none" for updated_on field, but it will never be "none".

Either we allow a query where "update_on = created_on", or we set updated_on to null on creation.
--------------------------------------------------------------------------------
Ketki Vahalia wrote:
> I agree that it is not necessarily incorrect to have "update time = creation time". The gap is that the query feature has the option of selecting "none" for updated_on field, but it will never be "none".

That's a true defect, indeed.

> Either we allow a query where "update_on = created_on", or we set updated_on to null on creation.

Would be easier to handle the "none" case as "update_on = created_on" behind the scenes (or replace it with some "never" entry for vocabulary consistency with other filters).

--------------------------------------------------------------------------------
I am new to Ruby and Rails (am an embedded systems engineer by training and experience). Can someone give me a pointer on where to look in the code. I can possibly fix this myself, if given some help. Thanks!
--------------------------------------------------------------------------------
The attached patch fixes the behavior for none and any operators as following:
* none: returns all issues without updates (updated_on = created_on)
* any: returns all issues that have an update (updated_on > created_on)
--------------------------------------------------------------------------------
Attached new version with a small fix (replaced in test the word *bigger* with *greater*).
--------------------------------------------------------------------------------
Thanks Marius, the patch works fine. But I have found a UI issue.

Although the filter is set to "none", values are displayed in "Updated" column. I think that it is natural that nothing is displayed there if the filter is set to "none".

!15226-ui-inconsistency.png!
--------------------------------------------------------------------------------
Go MAEDA wrote:
> Although the filter is set to "none", values are displayed in "Updated" column. I think that it is natural that nothing is displayed there if the filter is set to "none".

I think that we should discuss this UI issue in a separate issue because it is a general UI issue, not only when having the Updated none filter.

Do you consider natural to have values in the "Updated" column for every issue without updates even if this filter is not set?

--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Do you consider natural to have values in the "Updated" column for every issue without updates even if this filter is not set?

No, it is very strange. I can understand what you are saying. Currently, I have no idea to resolve this UI issue.
--------------------------------------------------------------------------------
Although the patch has a small UI issue (#15226#note-7), I think it is a bigger problem that filter "updated = none" does not work.
Setting target version to 3.4.0.
--------------------------------------------------------------------------------
Please correct me if I am wrong - It seems that Created = Updates for new issues is the design choice, hence current behaviour is expected. If we need to apply this patch, shouldn't we reconsider the original design decision? i.e. dont enter updated date when a new issue is added? I think the current solution may potentially confuse our users.(because it's been inconsistent with filters of other date fields)
--------------------------------------------------------------------------------
Kush Suryavanshi wrote:
> Correct me if I am wrong - It seems that Created = Updates for new issues is the design choice, hence current behaviour is expected. If we need to apply this patch, shouldn't we reconsider the original design decision? i.e. dont enter updated date when a new issue is added?

Yes, it seems a design choice, but from my checks it has more implications.

In my opinion, we can solve the UI issue by hiding the update date for issues without updates (created = updated), but I prefer to wait for Jean-Philippe Lang feedback before creating the patch.

--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> In my opinion, we can solve the UI issue by hiding the update date for issues without updates (created = updated), but I prefer to wait for Jean-Philippe Lang feedback before creating the patch.

I agree, the updated_on column is filled by Rails on the issue creation, I don't want to change that. But it's still possible to hide the timestamp on the issue list if it equals created_on. Not sure if it's a desirable change.
Your patch that fixes the filter is committed anyway, thanks.
--------------------------------------------------------------------------------
Ok. Thanks both of you for clarification. I think we can solve the UI issue through JavaScript, at least for us.
--------------------------------------------------------------------------------