refactor(reactQuery): adopt Orval's useAccessLogsList DEV-872

[Akuukis]

🗒️ Checklist

1. run linter locally
2. update developer docs (API, README, inline, etc.), if any
3. for user-facing doc changes create a Zulip thread at #Support Docs Updates, if any
4. draft PR with a title <type>(<scope>)<!>: <title> DEV-1234
5. assign yourself, tag PR: at least Front end and/or Back end or workflow
6. fill in the template below and delete template comments
7. review thyself: read the diff and repro the preview as written
8. open PR & confirm that CI passes & request reviewers, if needed
9. delete this section before merging

👀 Preview steps

In short, nothing changes.

1. ℹ️ go to http://kf.kobo.local/#/account/security
2. have 10+ access log entries
3. 🟢 notice that pagination loads fresh data nicely while placeholding old data in background
4. 🟢 notice that exporting access logs still works

[magicznyleszek]

Overall this is clean and nice, I found one issue though

[magicznyleszek]

I think I didn't test this change propertly in the other PR. When I visit /account/security I get 403 and the list of logs don't appear. Console says:

GET http://kf.local.kbtdev.org/api/v2/access-logs/?limit=10&offset=0 [HTTP/1.1 403 Forbidden 54ms]

[Akuukis]

hmm, it works for me, both on the PR and main 🤔

[magicznyleszek]

Copied from Zulip:

I think I have figured this out finally! There are two things in here:

1. On kf.main, when I visit account/security, the network shows call to /api/v2/access-logs/me/?limit=10&offset=0 but when I visit the PR branch locally, the call is different: /api/v2/access-logs/?limit=10&offset=0 (the difference is /me part). This was very obvious but it took some time before I have noticed it because I thought this was something more complex :D
2. Now the puzzle was also why it works for you. I tested it locally on a user created through /admin and "log in as". When I logged in as my superuser, everything was fine, or rather the 403 problem didn't happen. It is because the /api/v2/acces-logs/ endpoint is for superusers only. It wasn't available for my regular user. I'm assuming you were testing things with superuser account.

So my guess is that the fix is using useAccessLogsMeList instead of useAccessLogs. Unfortunately it requires a bit more work than replacing few lines of code