Searching on creation and modification dates filtering by user not working as expected

edited November 15 in General Support

Application version 1.8 Schema version 177 Type release GIT

I used to make a lot of use of the option to search objects etc. on creation and modification dates, filtering by user like: (modified.demo:"2016").

For a period of time I have not used this option.

In the meantime I updated my CollectivAccess version to 1.8.

Now I find that using the option gives strange results. No matter what user I apply, the search results are always the same number of objects etc.

It appears like the system cannot distiguish the different users.

In the demo sytem (demo.collectiveaccess.org) this behaviour does not appear so it seems to be related to my setup.

Does anyone have any clue what could cause this? (and how to fix it)

Comments

  • It seems to be locale related.

    I just changed my system setup from Dutch to English, and the results came back as expected.

    I will check my translation files

  • I have reverted to the original translations files with no results.

    Switching to English(en_US) or Belgium(nl_BE) I do get the expected results.

    What could be wrong with the dutch(nl_NL) localisation that causes this?

  • Just to confirm, you are using the same "modified" (in English) syntax no matter the locale?

  • Yes, I used "created" and "modified" as search terms in en_US, nl_NL and nl_BE.

    I get expected results in en_US and nl_BE.

    It worked fine in the past in nl_NL, but not anymore.

    Should I use the dutch (translated) terms instead?

    Then "created" would be "aangemaakt" and "modified" would be "gewijzigd" I assume.

  • I will in a while. I am coocking right now.

  • I just tried.

    Translated terms do not give the expected results.

  • It is not a big deal. I can switch to nl_BE to get the required results and still have a dutch translation.

    It is just that I am curious why it stopped working for nl_NL.

  • Me too. I'll try to reproduce the problem.

  • The issue does not occur in the demo system (as far as I can see).

    That would imply it could be related to my specific setup.

    But then why only when switching to locale nl_NL?

    The strange thing is: The messages.po files for nl_NL and nl_BE that I have currently installed are (exept for a different revision date) indentical.

    I am using the files from develop, downloaded on 27-04-2022.

  • edited November 17

    I have just downloaded and installed the latest code from develop.

    Using the stock nl_NL and nl_BE files and a copy of my online profile and setup the results for searches comes out as expected if i set locale to Dutch (nl_NL) in my local test server.

    At the moment I am uploding the new code to my online test serverver. I will check tomorrow if results on that server also behave as expected and report the results.

  • thanks for testing this!

  • edited November 17

    I can confirm the latest development code gives results as expected on my online testing server (with the stock nl_NL language file).

    I can also confirm the issue existed in all the previous 1.8 versions that I have tried, and did not occur in the last 1.7 version that I tried (1.7.11).

    The last thing to try is using a complete nl_NL translation file for the latest develop code.

    I will do that tomorrow.

  • The searsch results are still as expected after replacing the stock nl_NL file with a completed copy.

    So it seems irregularitys with search results in the latest development code.

  • When you write "completed copy" what do you mean? Are you running this with your own nl_NL locale files?

  • Yes, I used POEdit (and Transifex with the resource: app/locale/messages.pot (develop)) to translate all the lines.

    In this case I downloaded the completed translation from transifex and checked it one more time in POEdit.

    I did put the completed translation in a sub folder of the nl_NL folder called local.

  • Ok. I'll see about integrating that locale, as that's where the problem lies most likely.

  • I am sorry, I made an error in my previous post.

    I wrote: So it seems irregularitys with search results in the latest development code.

    That must be: So it seems there are no irregularitys with search results in the latest development code.

    The instruction to put my own translation in the subfolder nl_NL/local came from the old manual.

    I cannot find that info in the new manual.

    If the nl_NL/local folder is not used anymore, I assume the translation will fall back to the (stock) translation in nl_NL folder

  • Is there a problem to solver here or not?

  • No, not anymore, as far as I can see.

Sign In or Register to comment.