Redmine

Hwllo Florian,

I'll try to test it within the next 24h.

I'll keep you updated.

Hello Florian,

I am sorry to have to ask but this is the first time I tried to apply a patch. And something went wrong. I tried both ways described in your manual but both fail. Here is the terminal output:

-- Here I reckon that this patch is not supposed to be applied with "patch", as its content looks more like git.

redmine@aserver:/redmine/redmine-7.0.0$ patch p0 < 0001-Keep-the-sort-order-of-a-saved-query-in-the-session.patch
can't find file to patch at input line 5
Perhaps you used the wrong p or --strip option?
The text leading up to this was:
------------------------- |diff --git a/app/controllers/issues_controller.rb b/app/controllers/issues_controller.rb |index 144542a73..d7b2694bd 100644 |--- a/app/controllers/issues_controller.rb |+++ b/app/controllers/issues_controller.rb
--------------------------
File to patch:

-- But then I am not sure why the GIT-way fails as well.

redmine@aserver:/redmine/redmine-7.0.0$ git apply 0001-Keep-the-sort-order-of-a-saved-query-in-the-session-.patch
error: patch failed: app/controllers/issues_controller.rb:552
error: app/controllers/issues_controller.rb: patch does not apply
error: patch failed: app/helpers/queries_helper.rb:386
error: app/helpers/queries_helper.rb: patch does not apply
error: patch failed: test/functional/issues_controller_test.rb:2725
error: test/functional/issues_controller_test.rb: patch does not apply
redmine@aserver:/redmine/redmine-7.0.0$

Do you have any hint for me?

Hi Maik,

no problem. Use -p1 instead of -p0 (run it in /redmine/redmine-7.0.0):

patch -p1 --dry-run < 0001-Keep-the-sort-order-of-a-saved-query-in-the-session-.patch
patch -p1 < 0001-Keep-the-sort-order-of-a-saved-query-in-the-session-.patch

If the first command reports no "FAILED", run the second one and restart Redmine. To undo it: patch -p1 -R < 0001-Keep-the-sort-order-of-a-saved-query-in-the-session-.patch

(git apply most likely failed because the file got Windows line endings when it was copied to the server; patch handles that.)

This is the result of the dry run. Can I fix this in nano, maybe?

checking file app/controllers/issues_controller.rb
Hunk #1 FAILED at 552 (different line endings).
1 out of 1 hunk FAILED
checking file app/helpers/queries_helper.rb
Hunk #1 FAILED at 386 (different line endings).
Hunk #2 FAILED at 416 (different line endings).
2 out of 2 hunks FAILED
checking file test/functional/issues_controller_test.rb
Hunk #1 FAILED at 2725 (different line endings).
1 out of 1 hunk FAILED

Hi Maik, I answered in the forum to keep this issue short: Applying the patch from #44406 fails with CRLF line endings

Hello Florian,

First of all, I can confirm that the first patch does what it is supposed to do. The manually set table sort order of the current query is being kept no matter what tab I click in between. Many thanks for that.

And even more appreciation for the delivery of the second patch at lightspeed. I'll right now implement it and check the system's behavior. I'll update this ticket afterwards.

Hello Florian,

Here is my result:

I could patch the system without any problem. The server restarted properly afterward. As well I could find the newly implemented checkbox inside each query.

But unfortunately, there is a problem I came across. I ran the tests in my test environment which is actually the same Redmine Version as on the productive server. So this problem would also occur on the main server.

I tested with "personal" queries and "global" queries and I also tested as Administrator and as a normal User. Both did not make any difference, wich is good.

But I faced two issues. The first glitch is, that the sort order gets lost when there is at least one query that does not apply the new feature (checkbox unchecked). As expected it then uses its default sort order, but when I get back to a query that is supposed to memorize the previous manually set sort order, this order is lost. Even this query sorts by its default again.

When I check the checkbox in all queries, the memorization works.

Which leads to glitch number two. The last sort order is being applied for all queries. So let's say I set a manual sort order in query1 and switch to query3, then the previous sort order of query1 is being applied for query3 as well. Changing the sort order of query3 and jumping back to query1 applies query3's sort order to query1. There seems not to be one memory for each but only one memory for all queries.

I'am terribly sorry to have to report this, because I really appreciate the effort you put into this requirement, but as long as the sort order is kind of being interited when switch among queries, it still does not fit my colleagues needs.

Thanks for testing, Maik. Before I rework the patch, I would like to agree on the behavior. There are two possible variants:

Variant 1: the own sort order is carried over to the next query with the new option

• When the list is sorted by clicking on a column header, this sort order is carried over when switching to a query with the option.
• When switching to a query without the option, its sort order is applied and the own sort order is forgotten, also for the following queries.
• The first problem from note-9 remains by design: after switching through a query without the option, the following queries with the option use their own sort order again.
• The second problem from note-9 remains as well: there is no sort order per query. Switching from query 3 to query 1 carries the sort order of query 3 over to query 1.

Variant 2: each query remembers its own sort order

• When a query is sorted by clicking on a column header, this sort order is remembered for this query in the session.
• When the query is selected again later, its remembered sort order is used. Queries that were never sorted manually use their own sort order.
• This fixes both problems from note-9. It is what was originally requested in this issue ("each view remembers its table setup for the session").
• This could work with or without the option on the query.
• It needs more space in the session, which is stored in a cookie limited to about 4 KB. The number of remembered queries would have to be limited.

Example with query 1 (sorted by priority), query 2 without the option (sorted by due date) and query 3 (sorted by status), all other queries with the option:

In both variants, nothing is stored permanently: the remembered sort orders are only kept in the session of the user. Other users, including users of the same public or global queries, are not affected and still get the sort order of the query.

I would prefer variant 1: it needs no additional data in the session, only a check when switching queries, and the behavior stays simple.
Which variant fits the needs of your colleague better?

Hi Florian,

Although I see your point in keeping it simple, the answer is, that option 2 is definitely the wanted behavior.

Each query's view is expected to keep its own manually adjusted sort order inside the current session. Independantly for each user.

So I'd actually agree that the option-checkbox won't be needed in my particular case, as they will ask me to activate it on all queries anyway. You can remove it, if you prefer it.

Just to explain why this is necessary:

The entire company has, back then, defined round about 10 workflow steps (represented by queries that filter for the matching values) for passing an issue through the workflow. From the initial request by a new client until the generation of an invoice. They all have to use the same set of global queries which have only one predifined sort order each. No one uaes local/personal queries.

But each of them has individual habits concerning data represenation. And thus, the default sort order does not fit the need of each staff member. So they adjusted the sort orders of each query individually inside their sessions. Which perfectly persisted all day long even when they switched among them, and it worked for years. Until I came along and replaced release 3.3.3 by 7.0.0 for severe security reasons an the need to keep up with the latest security features as 2FA and stuff. This now secures the data by state of the art mechanisms but destroyed their accustomed way of working. And this is why they ask me frequently to do something about it.

Many thanks in advance, that you support me in this case.

Hi Maik,

Since a per-query sort order in the session is unlikely to make it into Redmine core, I implemented variant 2 as a plugin:

Redmine query sort memory

About the "lightspeed": I have to confess I had some help from Claude. Turns out the speed of light is still the limit, but only because the AI has to wait for me to read its code. ;-)
Honestly, tools like this are going to turn the way we write software upside down.

Please let's continue the discussion, bug reports and feature requests on GitHub:
flowalchs/redmine_query_sort_memory

The core defect fix for saved queries is still tracked in #44667.

Hi Florian,

just to make it visible to all Users, that might stumble somewhen into this issue:

Your solution perfectly works. From my point of view this ticket is solved. And it is absolutely understandable and okay for me, putting this into a plugin.

Many thanks for that!

PS: Sorry, but I could not find any option to put a comment in GitHub although I have an account and am logged in.

Just one small remark. In the README-section in Github you mention, that there is nothing else necessary but putting the plugin into the plugins-folder and restart Redmine. This is almost true.

I'd suggest to recommend in your README at least to run "bundle install" once, because I was lacking the "simplecov-cobertura" gem which your plugin needs. I was wondering why the Redmine-server did not start again. Thanks to the test you provided I found it out.

After running bundle install everything was fine.