Defect #15226
closed
Searching for issues with "updated = none" always returns zero results
0%
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
Updated by Gurvan Le Dromaguet about 11 years ago
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 ?
Updated by Ketki Vahalia about 11 years ago
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.
Updated by Etienne Massip about 11 years ago
- 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).
Updated by Ketki Vahalia about 11 years ago
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!
Updated by Marius BĂLTEANU almost 8 years ago
- none: returns all issues without updates (updated_on = created_on)
- any: returns all issues that have an update (updated_on > created_on)
Updated by Marius BĂLTEANU almost 8 years ago
Attached new version with a small fix (replaced in test the word bigger with greater).
Updated by Go MAEDA almost 8 years ago
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".
Updated by Marius BĂLTEANU almost 8 years ago
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?
Updated by Go MAEDA almost 8 years ago
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.
Updated by Go MAEDA almost 8 years ago
- 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.
Updated by Kush Suryavanshi almost 8 years ago
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)
Updated by Marius BĂLTEANU almost 8 years ago
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.
Updated by Jean-Philippe Lang almost 8 years ago
- 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.
Updated by Kush Suryavanshi almost 8 years ago
Ok. Thanks both of you for clarification. I think we can solve the UI issue through JavaScript, at least for us.