✨ Deliver UserResource in StatusResource

[jheubuch]

This PR implements, that within the StatusResource the whole UserResource will be transmitted and not just bits of it.

Open questions:

• When should the other fields be scheduled for deprecation?
• At the moment I named the property userDetails since user was already taken by the ID. Maybe you have a better name? (In future after deleting the conflicting fields, it could be renamed to user again)

[jheubuch]

Could also be interesting for you, @marhei and @bendix-dev

[MrKrisKrisu]

Generell bin ich dabei - ich würde dann, wenn der Key user frei wird die userDetails nochmal umbenennen (sorry, API-Consumer.)

Die Änderung könnte so aber die API Responses stark verlangsamen. Wir sollten an der Stelle Resourcen nutzen, die weniger viele Daten ausgeben. Bei jedem Status z.B. die totale trainDistance und trainDuration auszugeben ist bisschen much.

[jheubuch]

Generell bin ich dabei - ich würde dann, wenn der Key user frei wird die userDetails nochmal umbenennen (sorry, API-Consumer.)

Find ich gut :)

Die Änderung könnte so aber die API Responses stark verlangsamen. Wir sollten an der Stelle Resourcen nutzen, die weniger viele Daten ausgeben. Bei jedem Status z.B. die totale trainDistance und trainDuration auszugeben ist bisschen much.

Also quasi eine "schlanke" UserResource, die das wichtigste Zeug ohne Berechnungen beinhaltet?

[MrKrisKrisu]

Also quasi eine "schlanke" UserResource, die das wichtigste Zeug ohne Berechnungen beinhaltet?

Exakt! I mean, was braucht man an der Stelle?
ID, username, displayname, profilePicture, ... würde (mir) wahrscheinlich schon reichen.

Einwände? (cc @marhei, @bendix-dev, @vainamov, @HerrLevin)

[vainamov]

Passt von meiner Seite her! Die Umbenennung zurück in user ist auf jeden Fall sinnvoll und die vorgeschlagenen Felder sind für uns auch ausreichend 👍

[jheubuch]

I mean, was braucht man an der Stelle?
ID, username, displayname, profilePicture, ... würde (mir) wahrscheinlich schon reichen.

Ich hätte gerne noch die URL zum Mastodon-Account (das war die Intention hinter dem PR), aber sonst wäre ich auch glücklich :)

[bendix-dev]

Passt für mich, ich brauche fürs Erste nur die Felder, die auch vorher schon da waren.

[MrKrisKrisu]

Deprecation notice

Note

Backwards compatibility guaranteed until August 2024.

The StatusResource is now returning the whole UserResource for the user who created it in the userDetails field.
Thus the following fields of the StatusResource are now marked as deprecated and will be removed after August 2024.

• user
• username
• profilePicture
• preventIndex

This data is also available in the userDetails field.

{
  "data": {
    ...
    "user": 1, //deprecated - removed after 2024-08
    "username": "Gertrud123", //deprecated - removed after 2024-08
    "profilePicture": "https://traewelling.de/@Gertrud123/picture", //deprecated - removed after 2024-08
    "preventIndex": false, //deprecated - removed after 2024-08
    ...
    "userDetails": { //new - but deprecated. See below.
      "id": 1,
      "displayName": "Gertrud",
      "username": "Gertrud123",
      "profilePicture": "https://traewelling.de/@Gertrud123/picture",
      "mastodonUrl": "https://traewelling.social/@Gertrud123",
      "preventIndex": false
    }
  }
}

Looking ahead

The new key userDetails is already deprecated. We will rename this key to user in August 2024 after the current user attribute is removed. This will also be backwards compatible and will be announced accordingly.

---

(@Traewelling/api-consumer - to subscribe to breaking api changes see #2619)