refactor: less information sent per SessionUpdate (Backend)

[BenedictHomuth]

Description

Reduced the amount of information sent when a participant either changes his appearance or status on a board – as mention in #4217.

Before a PARTICIPANT_UPDATED event was published containing all information (account and board session). This is now split into two:

• Account (ID, name, avatar, account type) – for now remained PARTICIPANT_UPDATED
• Board Session (connected, banned, etc.) – named PARTICIPANT_SESSION_UPDATED

Changelog

• Simplified DB call, since we just need the session IDs and not all data per entry
• Updated the UpdatedUser function to publish only a dto.User to realtime
• Updated the dto.BoardSession – removing the whole account data and just leaving the id for identification
• Simplified the UpdatedSession function, since we only need to publish a dto.BoardSession to realtime for one board going foreward
• Adapted tests to use new dto.BoardSession

Next Steps

Since this is a breaking change, we need to modify the frontend to accommodate the backend changes. From my perspective either use this branch directly to make changes to the frontend or create a branch based on this one.

After the frontend changes are done, all tests should work again. For now, since I did not change the frontend, those tests obviously fail.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• The light- and dark-theme are both supported and tested
• The design was implemented and is responsive for all devices and screen sizes
• The application was tested in the most commonly used browsers (e.g. Chrome, Firefox, Safari)

[Schwehn42]

@BenedictHomuth I'll do the frontend part as soon as all/most of the other active PRs are merged into main – I'm worried that with such a change, there are just too many conflicts bound to happen 😅

[BenedictHomuth]

@BenedictHomuth I'll do the frontend part as soon as all/most of the other active PRs are merged into main – I'm worried that with such a change, there are just too many conflicts bound to happen 😅

Definitely worth its own release 😅
Hopefully, TS will make your life a little easier there. Let me know if I can help in any way.

[Schwehn42]

Update: I'm going to take a stab at this after the new store (related to #4423) is implemented.

[github-actions]

The deployment to the dev cluster was successful. You can find the deployment here: https://4246.development.scrumlr.fra.ics.inovex.io
This deployment is only for testing purposes and will be deleted after 1 week.
To redeploy rerun the workflow.
DO NOT STORE IMPORTANT DATA ON THIS DEPLOYMENT

Deployed Images

• ghcr.io/inovex/scrumlr.io/scrumlr-frontend:sha-fbed2c6

• ghcr.io/inovex/scrumlr.io/scrumlr-server:sha-fbed2c6

[octomind-dev]

🐙 Octomind

Test Report: 7/14 successful.

description	status	details
About Section Visibility Test	Passed ✅	click
change avatar	Failed ❌	click
check Privacy Policy	Passed ✅	click
check terms & conditions	Passed ✅	click
close cookie banner - front page	Passed ✅	click
close cookie banner - sign-in	Passed ✅	click
create and delete board columns	Failed ❌	click
create_and_delete_notes_and_actions_v2	Failed ❌	click
create lean coffee board	Failed ❌	click
edit_notes_and_actions_v5	Failed ❌	click
get started	Passed ✅	click
share_session	Failed ❌	click
sign-in	Passed ✅	click
test all ways to open the setup flow	Failed ❌	click

commit sha: fbed2c6

[Schwehn42]

I'm a little confused by the new workflow:

• The "INIT" event gives us only user IDs
• Both the endpoints for /participants/ and /participants/{id} gives us only user IDs

So we receive the session data but not the user data, and there is no endpoint to manually request it.
The user data is sent over the old "PARTICIPANT_UPDATED" event but that isn't activated when joining a board.

We need some initial form for the participant user names etc, after that we can receive session and user updates separately.