TudbuT/forgejo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

improve english ..

Browse source
This commit is contained in:
Michael Jerger 2024-01-18 20:06:56 +01:00
parent e1f27a950c
commit e926ea16e2
1 changed files with 2 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/unsure-where-to-put/adr-map-federated-person.md
View file

@ -211,7 +211,7 @@ classDiagram
We can use forgejo code (like star / unstar fkt.) without changes.
Introduce FederatedUser as new & persistence, no need for refactorings.
Introduce FederatedUser as new model & persistence.
But we use fields (User.EMail, User.Password) against their semantic, but we probably can handle the problems arising.
@ -299,12 +299,10 @@ classDiagram
### 4. Map to new FederatedPerson and introduce a common User interface
Cached FederatedPerson is mainly independent to existing User. At every place of interaction we have to enhance persistence & introduce a common User interface.
1. We map PersonId.asWbfinger() to FederatedPerson.ExternalID (e.g. 13@some.instan.ce).
2. We will have no semantic mismatch.
We can use forgejo code (like star / unstar fkt.) after refactorings only.
We can use forgejo code (like star / unstar fkt.) after refactorings only. At every place of interaction we have to enhance persistence (e.g. a find may have to query two tables now) & introduce a common User interface.
We introduce new model & persistence.