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

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. 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. 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 ### 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). 1. We map PersonId.asWbfinger() to FederatedPerson.ExternalID (e.g. 13@some.instan.ce).
2. We will have no semantic mismatch. 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. We introduce new model & persistence.