From e926ea16e276b6ca7650711165b4084679d1137f Mon Sep 17 00:00:00 2001 From: Michael Jerger Date: Thu, 18 Jan 2024 20:06:56 +0100 Subject: [PATCH] improve english .. --- docs/unsure-where-to-put/adr-map-federated-person.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/unsure-where-to-put/adr-map-federated-person.md b/docs/unsure-where-to-put/adr-map-federated-person.md index 2056269f1e..c124c10183 100644 --- a/docs/unsure-where-to-put/adr-map-federated-person.md +++ b/docs/unsure-where-to-put/adr-map-federated-person.md @@ -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.