Update "last visited" when gameboard viewed

[axlewin]

Makes the "last visited" date on a gameboard (as displayed on My Saved Decks) actually update when the gameboard is viewed.

This does introduce an extra DB write every time a saved gameboard is loaded, but I don't see a way around that if we want "last visited" to work.

[codecov]

Codecov Report

❌ Patch coverage is 29.62963% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 41.06%. Comparing base (b4f8f70) to head (5391c39).
⚠️ Report is 41 commits behind head on main.

Files with missing lines	Patch %	Lines
.../cl/dtg/isaac/dao/GameboardPersistenceManager.java	20.00%	11 Missing and 1 partial ⚠️
...a/uk/ac/cam/cl/dtg/isaac/api/GameboardsFacade.java	0.00%	5 Missing ⚠️
.../ac/cam/cl/dtg/isaac/api/managers/GameManager.java	71.42%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #817      +/-   ##
==========================================
+ Coverage   40.97%   41.06%   +0.09%     
==========================================
  Files         550      550              
  Lines       23555    23621      +66     
  Branches     2837     2851      +14     
==========================================
+ Hits         9652     9701      +49     
- Misses      13032    13043      +11     
- Partials      871      877       +6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sjd210]

I was just looking back to try to find out why this used to be working but stopped, and found out that we used to call the createOrUpdateUserLinkToGameboard method when visiting a page as well as on linking it (which we still do). This new approach of using a separate method for linking and visiting seems much more sensible, but it remains that this createOrUpdateUserLinkToGameboard method still talks about and has the functionality for just updating last_visited rather than setting the whole row.

This PR could go in as-is, but I'd rather we also clean up that other code while we're at it so it's explicitly just for linking, and this is explicitly just for visiting.

(This also highlights that there also used to be a DB write every time a saved gameboard was loaded in the past, which seemed to be fine, so I don't think there should be any problem with doing it again)

[axlewin]

Hmm. I think there are still some (admittedly niche) cases where we still want the update behaviour as a fallback for creating a new link. For example, when a user renames a gameboard (renameAndSaveGameboard), the board may or may not already be linked to their account (although the rename will fail if a non-admin tries to rename a board they don't own). If the board is already linked to their account, then updating "last visited" to reflect "last edited" seems sensible.

This also means if there's anywhere else where we might call createOrUpdateLinkToGameboard where a link already exists, the DB query won't needlessly fail when there is a sensible alternative operation we could perform.

I don't feel strongly about this though, perhaps it would be neater to always decide whether we're creating or updating at the manager level rather than relying on a fallback at the DB layer. Happy to change it if you still prefer that approach!

[sjd210]

@axlewin Your example of renameAndSaveGameboard is currently only usable via the Swagger UI - in which case I think it's fine for a lastVisited field to not be updated (+ I think we have good reason that it's not further available. I can imagine it being quite confusing for a student to encounter a completed board with a name they don't recognise).

Even if it were more widely available, I think that renaming/editing a gameboard is a distinct action from visiting it and that I wouldn't be surprised for a "Last visited on" to not update if I hadn't actually done any visiting. There don't seem to be any other ways for the function to be called beyond an initial link and this renaming currently, but even if there were I still support the idea of separating the use-cases of the functions at the manager level anyway - so yes, I still prefer my above approach.

[sjd210]

I prefer this split, and think that this still works so 👍