Defect #15226
closed
Searching for issues with "updated = none" always returns zero results
Added by Ketki Vahalia over 10 years ago.
Updated over 7 years ago.
Description
I am using Redmine 2.2.4. Thanks for the great open source tool.
I would like to find new issues that have been added, but not updated. I tried to use the filter "updated" set to "none". I know there are issues without any update, but I always get "No data to display" message.
A little poking around the DB showed me that updated_on is set to created_on timestamp. So updated_on is not empty for new issues. Looking at the code, I noticed there is before_save 'force_updated_on_change' function in issue model. I am guessing that is setting the update_on field for new issues as well.
This seems incorrect, since clearly we wanted to query the issues with empty 'updated_on' field, as it is available in the filters. Can someone help fix this?
Files
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.
- Status changed from New to Confirmed
- Target version set to Candidate for next minor release
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".
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.
- Target version changed from Candidate for next minor release to 3.4.0
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.
- Status changed from Confirmed to Closed
- Assignee set to Jean-Philippe Lang
- Resolution set to Fixed
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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by