Bug 38630 - Make the REST API respect KohaOpacLanguage cookie
Summary: Make the REST API respect KohaOpacLanguage cookie
Status: BLOCKED
Alias: None
Product: Koha
Classification: Unclassified
Component: Holidays (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Julian Maurice
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on: 32551
Blocks:
  Show dependency treegraph
 
Reported: 2024-12-05 11:22 UTC by Julian Maurice
Modified: 2025-01-10 10:59 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 38630: Make the REST API respect KohaOpacLanguage cookie (15.52 KB, patch)
2024-12-05 11:23 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38630: Make the REST API respect KohaOpacLanguage cookie (15.57 KB, patch)
2025-01-08 11:07 UTC, David Nind
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2024-12-05 11:22:51 UTC
Continuation of bug 32551
Comment 1 Julian Maurice 2024-12-05 11:23:44 UTC
Created attachment 175238 [details] [review]
Bug 38630: Make the REST API respect KohaOpacLanguage cookie

The REST API can return translated strings to the opac or staff
interface, so it should respect the KohaOpacLanguage cookie and return
translations in the same language than the interface.

Test plan:
1. Do not apply patch yet
2. Log in to koha staff interface
3. Use the browser's devtools to get the value of CGISESSID cookie
4. Make sure you have at least 2 languages installed ('en' + another
   one - I'll use 'fr-FR' as an example in this test plan)
5. Find an item and note its itemnumber and itemtype
6. Go translate this itemtype's description (admin » item types » edit
   item type » translate). Add a translation for 'en' and another one
   for your language.
7. Close your browser tab (do not logout) and restart Koha to flush the
   memory cache.
8. Execute the following commands (replace variables by the correct
   value):

    curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \
        -H 'x-koha-embed: +strings' \
        -H "Cookie: KohaOpacLanguage=en; CGISESSID=$CGISESSID" \
        | jq -r '._strings.item_type_id.str'

   If you do not have jq, it can be found in most distributions
   packages. Or you could inspect the JSON manually at the path
   /_strings/item_type_id/str

   Restart Koha again, and execute the same command but with your
   language set in KohaOpacLanguage cookie:

    curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \
        -H 'x-koha-embed: +strings' \
        -H "Cookie: KohaOpacLanguage=fr-FR; CGISESSID=$CGISESSID" \
        | jq -r '._strings.item_type_id.str'

   Depending on how Koha sort the languages (not sure how it's done),
   you should get either the 'en' one or the 'fr-FR' one, but the
   important thing is you should get the same translation, no matter
   what the value of KohaOpacLanguage is, which is the issue this patch
   is trying to fix.
9. Apply the patch and restart Koha
10. Repeat step 8. This time you should get the translation
    corresponding to the language set in KohaOpacLanguage cookie

Side note:
* The need to restart Koha before each request is due to a bug (see bug
  38454). If already pushed when you're testing this one, you don't have
  to restart.
Comment 2 David Nind 2025-01-03 19:03:09 UTC
I had a go at testing, but didn't have any luck with step 8.

1. Are these commands issued from within the KTD shell, or your local machine? I tried both (with a restart after each command).

2. I get null as the result:

curl -sSL "127.0.0.1:8081/api/v1/items/578" \
-H 'x-koha-embed: +strings' \
-H "Cookie: KohaOpacLanguage=en; CGISESSID=f44da5bb4f1805fced9004f8dab49160" \
| jq -r '._strings.item_type_id.str'
null

3. The session id keeps on changing. If I go to access the staff interface again, I get session time out, please log in again, and the session id is different (as expected ?).

Testing notes (using KTD):
1. Step 3: 
   - Chromium-based browsers: More tools > Developer tools > Application > Storage > Cookies > [Select website] > CGISESSID
2. Step 4:
   - Install a translation: koha-translate --install fr-FR --dev kohadev
   - Koha administration > System preferences > I18/L10N > OPACLanguages and StaffInterfaceLanguages [select languages to enable], opaclanguagedisplay - allow
3. Step 8, from within KTD (also tried from local machine):
   - sudo apt-get install jq
   - first execution - result = null:
curl -sSL "127.0.0.1:8081/api/v1/items/578" \
-H 'x-koha-embed: +strings' \
-H "Cookie: KohaOpacLanguage=en; CGISESSID=f44da5bb4f1805fced9004f8dab49160" \
| jq -r '._strings.item_type_id.str'
null
Comment 3 Julian Maurice 2025-01-06 07:27:37 UTC
(In reply to David Nind from comment #2)
> I had a go at testing, but didn't have any luck with step 8.
> 
> 1. Are these commands issued from within the KTD shell, or your local
> machine? I tried both (with a restart after each command).
They should be run from the same machine that is running your browser (so probably your local machine)

> 2. I get null as the result:
> 
> curl -sSL "127.0.0.1:8081/api/v1/items/578" \
> -H 'x-koha-embed: +strings' \
> -H "Cookie: KohaOpacLanguage=en; CGISESSID=f44da5bb4f1805fced9004f8dab49160"
> \
> | jq -r '._strings.item_type_id.str'
> null
Can you try to remove the '| jq ...' part to see the full JSON response ?

> 3. The session id keeps on changing. If I go to access the staff interface
> again, I get session time out, please log in again, and the session id is
> different (as expected ?).
Maybe you have SessionRestrictionByIP enabled and running the command from
within KTD logged you out
Comment 4 David Nind 2025-01-08 11:07:19 UTC
Created attachment 176226 [details] [review]
Bug 38630: Make the REST API respect KohaOpacLanguage cookie

The REST API can return translated strings to the opac or staff
interface, so it should respect the KohaOpacLanguage cookie and return
translations in the same language than the interface.

Test plan:
1. Do not apply patch yet
2. Log in to koha staff interface
3. Use the browser's devtools to get the value of CGISESSID cookie
4. Make sure you have at least 2 languages installed ('en' + another
   one - I'll use 'fr-FR' as an example in this test plan)
5. Find an item and note its itemnumber and itemtype
6. Go translate this itemtype's description (admin » item types » edit
   item type » translate). Add a translation for 'en' and another one
   for your language.
7. Close your browser tab (do not logout) and restart Koha to flush the
   memory cache.
8. Execute the following commands (replace variables by the correct
   value):

    curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \
        -H 'x-koha-embed: +strings' \
        -H "Cookie: KohaOpacLanguage=en; CGISESSID=$CGISESSID" \
        | jq -r '._strings.item_type_id.str'

   If you do not have jq, it can be found in most distributions
   packages. Or you could inspect the JSON manually at the path
   /_strings/item_type_id/str

   Restart Koha again, and execute the same command but with your
   language set in KohaOpacLanguage cookie:

    curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \
        -H 'x-koha-embed: +strings' \
        -H "Cookie: KohaOpacLanguage=fr-FR; CGISESSID=$CGISESSID" \
        | jq -r '._strings.item_type_id.str'

   Depending on how Koha sort the languages (not sure how it's done),
   you should get either the 'en' one or the 'fr-FR' one, but the
   important thing is you should get the same translation, no matter
   what the value of KohaOpacLanguage is, which is the issue this patch
   is trying to fix.
9. Apply the patch and restart Koha
10. Repeat step 8. This time you should get the translation
    corresponding to the language set in KohaOpacLanguage cookie

Side note:
* The need to restart Koha before each request is due to a bug (see bug
  38454). If already pushed when you're testing this one, you don't have
  to restart.

Signed-off-by: David Nind <david@davidnind.com>
Comment 5 David Nind 2025-01-08 11:09:03 UTC
(In reply to Julian Maurice from comment #3)
> (In reply to David Nind from comment #2)

> Maybe you have SessionRestrictionByIP enabled and running the command from
> within KTD logged you out

I turned off SessionRestrictionByIP and StaffLoginLibraryBasedOnIP (both enabled by default in KTD), and everything now works as per the test plan.

Thanks Julian!
Comment 6 Marcel de Rooy 2025-01-10 10:16:57 UTC
Looking here
Comment 7 Marcel de Rooy 2025-01-10 10:23:13 UTC
The tidy stuff and a POD failure:

 WARN   C4/Languages.pm
   WARN   tidiness
                The file is less tidy than before (bad/messy lines before: 210, now: 212)

 FAIL   Koha/Language.pm
   FAIL   pod coverage
                POD is missing for get_requested_language
                POD is missing for set_requested_language
   WARN   tidiness
                The file is less tidy than before (bad/messy lines before: 0, now: 2)

 WARN   t/Languages.t
   WARN   tidiness
                The file is less tidy than before (bad/messy lines before: 10, now: 16)

 WARN   t/db_dependent/api/v1/items.t
   WARN   tidiness
                The file is less tidy than before (bad/messy lines before: 180, now: 184)
Comment 8 Katrin Fischer 2025-01-10 10:26:54 UTC
(In reply to Marcel de Rooy from comment #7)
> The tidy stuff and a POD failure:
> 
>  WARN   C4/Languages.pm
>    WARN   tidiness
>                 The file is less tidy than before (bad/messy lines before:
> 210, now: 212)
> 
>  FAIL   Koha/Language.pm
>    FAIL   pod coverage
>                 POD is missing for get_requested_language
>                 POD is missing for set_requested_language
>    WARN   tidiness
>                 The file is less tidy than before (bad/messy lines before:
> 0, now: 2)
> 
>  WARN   t/Languages.t
>    WARN   tidiness
>                 The file is less tidy than before (bad/messy lines before:
> 10, now: 16)
> 
>  WARN   t/db_dependent/api/v1/items.t
>    WARN   tidiness
>                 The file is less tidy than before (bad/messy lines before:
> 180, now: 184)

As we plan to tidy the whole codebase quite soon (January/February), I think you can ignore the tidy warnings for now. POD should be checked of course.
Comment 9 Marcel de Rooy 2025-01-10 10:59:01 UTC
Will continue on this report early next week. No need to change status.