Gitea: Préparation à la fédération : Utilisateurs « distants » / ID fédéré

Cela dépend en fait vraiment de ce que sont les cas d'utilisation sur ce que l'utilisateur fédéré/externe sera capable de faire. S'ils ne peuvent pas héberger de référentiels, il est acceptable d'avoir une table d'utilisateurs fédérée et de déplacer le nom d'affichage, le nom d'utilisateur, etc. Cela nécessiterait une réécriture totale de chaque partie du code où la table utilisateur locale est utilisée pour maintenant utiliser une table utilisateur fédérée qui pourrait être un sacré travail :)

Je suis tout à fait d'accord @lafriks. Avant de commencer, nous devons connaître quelques questions :

1. Qui veut cette fonctionnalité ? Utilisateur personnel de gitea / Entreprises avec gitea privé / site d'hébergement Git via gitea ou autres ?
2. Pourquoi ont-ils besoin de cette fonctionnalité ?
3. Comment veulent-ils utiliser cette fonctionnalité ?

S'ils ne peuvent pas héberger de référentiels, il est acceptable d'avoir une table d'utilisateurs fédérée et de déplacer le nom d'affichage, le nom d'utilisateur, etc.

Les utilisateurs fédérés peuvent avoir des référentiels, mais hébergés sur l'instance de l'utilisateur.
En d'autres termes, vous n'avez pas seulement des utilisateurs fédérés, mais également des projets fédérés (y compris les repos, les problèmes, les PR, etc.). Mais cela sort du cadre de ce problème.

1. Qui veut cette fonctionnalité ? Utilisateur personnel de gitea / Entreprises avec gitea privé / site d'hébergement Git via gitea ou autres ?

Des gens comme moi qui n'aiment pas l'idée que le développement de logiciels libres et open-source soit centralisé sur des services, enfin, centralisés et non libres. (GitHub)

1. Pourquoi ont-ils besoin de cette fonctionnalité ?

Bien qu'il existe des alternatives gratuites comme Gitea et GitLab, leurs instances sont isolées les unes des autres et présentent donc des inconvénients d'utilisation. (Et sont soumis à des effets de réseau.)
Même si je suis motivé pour créer un compte sur, disons Debian GitLab, il est limité à cette instance.
Dans le pire des cas, chaque projet a sa propre instance et j'ai tellement de comptes à vérifier. (Oui, il y a des notifications par e-mail, mais nous voulons quelque chose sur le Web, sinon Git + ML suffirait également.)

1. Comment veulent-ils utiliser cette fonctionnalité ?

Pour une collaboration fédérée, brisant l'effet réseau de GitHub.

J'ai 1 compte sur mon instance d'accueil et je peux collaborer avec n'importe quel projet prenant en charge la fédération (c'est-à-dire ForgeFed ).

https://github.com/go-gitea/gitea/blob/7217b703e95a3ab01b69f91879fb4d6532f0b2c5/models/user.go#L94 -L97

Est-il exact que

• Name est le nom d'utilisateur ( criztovyl ) et
• FullName est le nom d'affichage ("Christoph Schulz")

?

Mais quelle est la raison de LowerName ? ( strings.ToLower(u.Name) )

Afin de ne pas utiliser lower(Name) dans les requêtes SQL.

Afin de ne pas utiliser lower(Name) dans les requêtes SQL.

Mais pourquoi du tout ? Je ne veux pas le changer, comprenez-le simplement. :)

J'ai commencé à jouer un peu et j'ai bêtement déplacé certains attributs de user.go (tapez User ) à un nouveau user_identity.go (tapez Identity ) et j'ai ajouté du code à AfterLoad qui remplit les anciens attributs avec les valeurs de l'identité.

Par la suite, j'ai rencontré des problèmes lors de l'écriture d'une migration qui déplace les attributs de User à Identity . Je vais approfondir cela en étudiant les migrations existantes et les documents xorm, mais je serais vraiment heureux d'avoir d'autres conseils. :)

Je partagerai quelques commits la prochaine fois.

Mais pourquoi du tout ? Je ne veux pas le changer, comprenez-le simplement. :)

Parce que le nom d'utilisateur est insensible à la casse, et lorsqu'un utilisateur envoie des requêtes telles que https://try.gitea.io/AxIFiVe ou https://try.gitea.io/Axifive, il faut rapidement trouver l'utilisateur unique, nous appelons donc simplement strings.ToLower(username) et envoie une simple requête SQL.
Convertir les champs en minuscules pour la sélection est une opération de base de données très coûteuse, il est beaucoup plus facile d'ajouter un deuxième champ.

J'ai promis du code.

Je viens de pousser le code avec lequel j'ai du mal, vous pouvez le trouver ici : https://github.com/criztovyl/gitea/blob/master/models/migrations/v200.go (200 pour faciliter la fusion/rebasage)

La ligne 30, la synchronisation du modèle Identity, fonctionne comme prévu : la table est créée.
Mais la ligne 35, la synchronisation du modèle User, ne semble pas fonctionner, la table a toujours les anciennes colonnes par la suite.

Sync2 n'ajoutera que des colonnes.

Si vous souhaitez supprimer des colonnes, vous devez utiliser :

https://github.com/go-gitea/gitea/blob/80bfd5145c7b159ebdad3746efe11378b282fa86/models/migrations/migrations.go#L348

Veuillez noter que les migrations ne doivent pas faire référence à des éléments dans les modèles ou ailleurs - ceux-ci pourraient être modifiés dans les migrations futures. Ils doivent être complètement autonomes - aucune référence à d'autres codes Gitea.

Donc:

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L30

Ici, vous devez réellement avoir une copie d'identité. De même ici :

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L14

Cela devait probablement être xorm: "-" auquel cas ce n'est probablement pas nécessaire dans la migration.

En regardant votre table d'identité proposée, comment se fait-il que vous ne puissiez pas utiliser login_source pour cela ?

Merci pour les astuces :)

Le problème avec login_source, pour autant que je l'ai analysé, est qu'il nécessite toujours que les noms d'utilisateur soient uniques.

Pour la fédération, les noms d'utilisateur ne sont pas uniques, seule l'identité l'est (où l'identifiant unique de ces identités est généralement un URI/IRI) ; les noms d'utilisateur ressemblent davantage à un nom d'affichage encore plus limité.

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L14

Cela devait probablement être xorm: "-" auquel cas ce n'est probablement pas nécessaire dans la migration.

Je vois, mais comment l'identité référencée par l'IdentityId est-elle remplie ? Est-ce automatique ou dois-je l'ajouter quelque part ?

Et si je crée la table initialement, j'ai toujours besoin du modèle d'identité, donc je ne peux pas le laisser de côté, n'est-ce pas ?

Et une autre question rapide; est-il possible d'exécuter l'instance gitea qui contient toutes les données de test des appareils dans sa base de données ?

Je suis parfois de type visuel. Par exemple, voudrais-je vérifier que le profil s'affiche toujours correctement, par exemple, a les bonnes affectations d'organisation.

Vous pouvez jeter un œil à https://github.com/go-gitea/gitea/blob/master/contrib/pr/checkout.go car il charge des appareils pour nous aider à vérifier les PR.

Vous pourriez peut-être faire une version modifiée.

go run -tags "sqlite sqlite_unlock_notify" contrib/pr/checkout.go -run fonctionne comme un charme :)

en plus de ne pas avoir de rechargement de code à chaud, mais je suppose que c'est un peu plus compliqué :D

Je suis tout à fait d'accord @lafriks. Avant de commencer, nous devons connaître quelques questions :

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

2. Why they need this feature?

3. How they want to use this feature?

Personnel

Utilisation personnelle, ce serait certainement une très bonne fonctionnalité. J'ai une instance où je stocke mes référentiels, publics et privés (pas tous mais beaucoup). Si quelqu'un veut collaborer sur eux, il doit avoir un utilisateur sur mon instance et cela fonctionne de la même manière dans l'autre sens, si je vois un projet quelque part sur une instance Gitea et que je veux collaborer, comme réparer quelque chose ou résoudre une demande de fonctionnalité, je devez y amener un utilisateur ou envoyer un e-mail de demande de tirage avec des liens diff/ref.

Si je peux inviter des utilisateurs d'autres instances sur un référentiel privé ou qu'ils peuvent simplement rejoindre leurs propres utilisateurs (si une instance spécifique n'est pas bloquée/sur liste noire), ce serait beaucoup plus facile.

Entreprise

Je ne sais pas si les entreprises vont l'utiliser, mais je vois des opportunités potentielles. À l'heure actuelle, la plupart des entreprises utilisent GitHub car tout le monde a un utilisateur GitHub et peut gérer les autorisations/équipes. En tant qu'entreprise (hypothétique), si je peux héberger mon propre Gitea où je peux inviter d'autres utilisateurs avec l'utilisateur Gitea de différentes instances et les mettre en équipes et leur donner des autorisations qui pourraient potentiellement lancer une nouvelle ère où une entreprise peut dire en toute sécurité "Oui nous pouvons utiliser Gitea parce que tout le monde peut en avoir un par lui-même", en particulier lorsque des groupes plus importants / des guerriers fédérés peuvent fournir des instances Gitea aux utilisateurs qui n'hébergent/ne peuvent pas héberger les leurs, comme Mastodon a beaucoup d'instances et vous pouvez en choisir une, en utiliser une et accédez à tout ce que vous voulez.

D'un autre côté, je vois que ce serait beaucoup de travail à faire et je ne sais pas si cela fonctionnerait et peut diviser les utilisateurs en fragments plus petits en fonction de la façon dont ils veulent l'utiliser.

Qui veut cette fonctionnalité ? Utilisateur personnel de gitea / Entreprises avec gitea privé / site d'hébergement Git via gitea ou autres ?

En tant qu'utilisateur personnel…

Pourquoi ont-ils besoin de cette fonctionnalité ?

Je ne veux pas créer de compte sur des centaines d'instances,

Comment veulent-ils utiliser cette fonctionnalité ?

juste pour signaler un problème. C'est pourquoi je ne le signale souvent pas. Pourrais-je le faire à partir d'une instance avec laquelle j'ai déjà un compte, quel que soit l'endroit où le référentiel en question est hébergé, les choses seraient différentes.

Btw : il en va de même pour les « PR/MR minimaux » contenant des correctifs ponctuels. Donc en bref : si je n'ai pas l'intention de « vraiment rejoindre » un projet, mais que j'apporte quand même mes 2 centimes.

Je suis tout à fait d'accord @lafriks. Avant de commencer, nous devons connaître quelques questions :

1. Qui veut cette fonctionnalité ? Utilisateur personnel de gitea / Entreprises avec gitea privé / site d'hébergement Git via gitea ou autres ?

Je suis un utilisateur personnel de Gitea qui collabore avec d'autres personnes telles que @a1batross. Nous avons tous les deux nos propres instances Gitea, mais j'aimerais pouvoir facilement contribuer au code de l'un de ses référentiels, par exemple avec une pull request inter-instance.

1. Pourquoi ont-ils besoin de cette fonctionnalité ?

Beaucoup plus facile que de créer un compte sur l'autre instance - et de cette façon, vous n'avez pas besoin d'avoir des enregistrements ouverts pour accepter le code des autres. Je ne veux pas d'un million de comptes Gitea.

1. Comment veulent-ils utiliser cette fonctionnalité ?

Les demandes de tirage et les problèmes inter-instances principalement. J'aimerais également que les organisations incluent des utilisateurs distants (afin qu'ils puissent directement pousser).

1. Qui veut cette fonctionnalité ? Utilisateur personnel de gitea / Entreprises avec gitea privé / site d'hébergement Git via gitea ou autres ?

Personnel car je pense que cela aidera surtout à réduire le nombre de comptes actifs pour eux.

Git héberge des sites Web car cela réduira l'effet de réseau et ils n'auraient pas à stocker les détails des comptes pour chaque personne qui est venue signaler un problème en même temps.

1. Pourquoi ont-ils besoin de cette fonctionnalité ?

Afin de faciliter la contribution à des projets étrangers, vous n'auriez pas besoin de créer un compte pour signaler un problème ou faire une correction rapide.

1. Comment veulent-ils utiliser cette fonctionnalité ?

Je voudrais l'utiliser pour n'avoir qu'une seule identité git et pas une tonne de comptes dans les référentiels Git associés à différents endroits.

J'aimerais pouvoir faire tout ce que je fais actuellement sur Gittea, GitHub et GitLab en un seul endroit. C'est-à-dire les problèmes, les demandes d'extraction/fusion, les organisations.

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Privé. L'exécution de mon propre serveur Git rend mes projets moins disponibles en raison de la plus petite infrastructure. Avoir la décentralisation et l'interopérabilité avec Github/GitLab rend mes projets aussi accessibles et plus disponibles que s'ils étaient sur ces plateformes. Pas besoin que tout le monde ait des comptes sur mon serveur le rend plus attractif pour les contributeurs.

2. Why they need this feature?

Intégration transparente. Utilisez l'interface avec laquelle vous souhaitez collaborer sur les projets que vous aimez.

3. How they want to use this feature?

L'autorité centrale sur mes serveurs et le fait que CI ou d'autres services cloud interagissent avec n'importe quel logiciel d'hébergement me donne les meilleures fonctionnalités que je veux. Pas besoin que tout le monde soit compatible avec toutes les différentes API de GitLab/GitHub/Gitea et toutes les plus petites.

Copie des retours fediverse de fr33domlover (équipe ForgeFed) :

La situation actuelle est que pour interagir avec un dépôt hébergé sur une forge comme Gitea ou GitLab ou githu8 etc. vous devez y avoir un compte. Chaque site Web de forge est une île distincte.

Si vous hébergez votre propre forge, vous établissez les règles, etc., mais vous êtes isolé. C'est plus difficile de te trouver. Beaucoup de gens craignent de recevoir moins de contributions s'ils quittaient githu8. Il faudrait aussi que les contributeurs créent un compte sur chaque forge.

Et githu8 est propriétaire et centralisé et n'est pas un projet communautaire par le peuple pour le peuple.

L'idée est que la visibilité de votre projet et l'accès à celui-ci ne dépendront pas du fait que le compte de l'utilisateur se trouve sur votre forge ou sur une autre forge. Vous pouvez créer un compte et participer partout. Recherche de projet, découverte, recommandations, etc. trouvez des trucs de tout le réseau. Aucune forge n'a plus de pouvoir sur les utilisateurs qu'une autre.

Exemples:

• Les organisations/équipes/groupes peuvent inclure des utilisateurs de différentes forges
• Vous pouvez pousser les commits vers les dépôts sur différentes forges
• Vous pouvez ouvrir des tickets, ouvrir des demandes de fusion, commenter, envoyer une révision de code, etc. à travers les forges
• Les dépôts, les serveurs CI, les wikis, les outils de suivi des problèmes, etc. peuvent se trouver sur différents serveurs et fonctionner ensemble de manière transparente

1. Comment veulent-ils utiliser cette fonctionnalité ?

En plus de ce que d'autres ont déjà mentionné : en surfant sur le Web, je rencontre des tonnes de projets intéressants qui existent sur leur propre instance gitea/gitlab. Je veux souvent juste mettre en vedette ces dépôts, mais la friction ici (inscription) est tout simplement trop élevée. Au lieu de cela, je les marque dans mon navigateur et oublie surtout de les vérifier plus tard (trop de marque-pages).

Sur github, j'utilise les étoiles à la fois comme moyen de mise en signet et comme signe d'appréciation pour le projet. Les projets d'intérêt particulier que je regarde, j'ai donc mon tableau de bord des notifications comme moyen facile de suivre l'activité.

Les étoiles peuvent être abusées, mais si un dépôt github a, disons, 14 000 étoiles, cela en dit long sur sa popularité et je peux être raisonnablement sûr que le projet est utile et de bonne qualité. Sur gitea / gitlab les étoiles ne me disent pas grand chose actuellement.

Idéalement, à l'avenir, j'aurai un - le mien - un endroit connecté à plusieurs autres où j'ai un aperçu de toutes mes activités de codage, quel que soit l'endroit où je les ai effectuées.

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Je suis un utilisateur personnel de Gitea
J'ai deux instances Gitea, une pour mon collectif artistique (où nous gardons le code de nos projets), et une autre pour moi (où je fais mon travail personnel et contractuel, et aussi quelques projets avec mes étudiants)

2. Why they need this feature?

Principalement parce que je ne veux pas utiliser GitHub ou ses concurrents.
Ce fil de questions est un bon exemple, nous avons tous besoin de comptes GitHub pour pouvoir participer à une conversation, alors qu'avec la fédération, nous pourrions utiliser nos comptes fédérés

3. How they want to use this feature?

Si Gitea et d'autres services étaient tous fédérés, en utilisant un protocole commun (ActivityPub), cela ouvrirait non seulement la possibilité d'interaction entre les services VCS fédérés, mais à l'ensemble de la fédération, vous seriez en mesure de commenter et de vous abonner au projet mises à jour de Mastodon, par exemple.

Faisant écho à ce que beaucoup d'autres utilisateurs disent, j'aimerais pouvoir permettre aux gens de contribuer facilement à mes projets, même simplement en créant des problèmes, sans avoir à ouvrir des inscriptions sur mon serveur, et j'aimerais être capable de créer des problèmes ou de fournir de minuscules contributions sans avoir à créer plus de comptes
Dans un monde idéal, je n'aurais plus de compte GitHub

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Je suis tous les 3.

1. Je suis un utilisateur personnel de gitea (activé et désactivé, principalement désactivé, voir la réponse à la partie 2).
2. Mon job de jour a (plusieurs !) instances Gitea internes/privées.
3. J'envisagerais de fournir un site Web d'hébergement git privé (c'est-à-dire sur invitation uniquement) via gitea (que j'utiliserais également personnellement) si forgefed était une option.

2. Why they need this feature?

En tant qu'utilisateur privé :
Le choix entre héberger vos données sur github, gitlab et "autre part" est grave.
Si je choisis github/gitlab, je suis à la merci de leurs décisions en tant que plate-forme et n'ai aucun contrôle sur mes données.
Si je choisis autre chose (par exemple ma propre instance gitea), il est difficile de découvrir le projet[1], et les contributions nécessitent soit d'avoir son propre compte (donc maintenant je suis un hébergeur de site ? c'est pas bien) ou d'aller par mail route (ce qui est restrictif, tout le monde n'aime pas non plus ce workflow).
Avec la fédération (même si elle n'est pas nécessairement forgée, mais idéalement interopérable entre divers services), j'obtiens le meilleur des deux mondes - on peut contribuer à partir de n'importe quelle instance en utilisant ses propres comptes, et découvrir n'importe lequel de mes projets hébergés localement, tout en garder le contrôle de mes données et de ma plateforme.

En tant qu'hébergeur d'entreprise :
Comme je l'ai mentionné, nous avons plusieurs instances de gitea, pour diverses raisons.
Nous serions intéressés par une fédération de liste blanche (c'est-à-dire où la fédération n'est activée que contre d'autres serveurs spécifiques) pour faciliter les échanges entre nos nœuds internes et ceux de partenaires logiciels arbitraires, sans nécessairement avoir besoin de leur donner un accès interne dans tous les cas.

En tant qu'hébergeur de site :
Prenez tout de la partie utilisateur privé - c'est maintenant l'argumentaire de vente aux utilisateurs potentiels.
Vous n'avez pas besoin de vous fier uniquement à « Eh bien, X est mauvais et je ne le suis pas » comme seul argument.
De plus, les coûts de migration des personnes vers votre service deviennent beaucoup plus faibles (voire négligeables).

3. How they want to use this feature?

En résumé / pour réitérer :

En tant qu'utilisateur privé (et hébergeur de site Web en ayant des utilisateurs qui ne sont effectivement que cela) :

• découvrez facilement des projets externes via la recherche (et laissez le vôtre être découvert)
• permettre de contribuer (y compris signaler des problèmes, commenter, etc.) à un projet donné sans avoir de compte sur son instance

En tant qu'utilisateur professionnel :

• fédération de liste blanche :
  
  
  
  • permettre la communication interne entre des nœuds à usages différents
  
  
  • permettre une communication zéro confiance et zéro privilège entre nos nœuds et ceux de divers partenaires logiciels
  
  

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Je le fais, à la fois pour mon gîte personnel et pour celui que nous utilisons au travail.

2. Why they need this feature?

Collaborer sur des projets sur d'autres instances forgées. Il ne devrait pas être nécessaire de créer un compte utilisateur sur chaque système. Dans le cas de mon instance privée, je ne voudrais pas donner un accès aléatoire à des personnes. Et pour l'exemple de l'entreprise, les non-employés ne peuvent évidemment pas y accéder.

3. How they want to use this feature?

Je l'utiliserais pour collaborer sur des projets, à la fois open source et propriétaires.

1. Qui veut cette fonctionnalité ? Utilisateur personnel de gitea / Entreprises avec gitea privé / site d'hébergement Git via gitea ou autres ?

Utilisateur personnel définitivement.

1. Pourquoi ont-ils besoin de cette fonctionnalité ?

L'open source est une question de collaboration. GitHub a généralisé l'open source en faisant du travail sur le code une chose sociale et en rendant trivial le signalement des problèmes et la contribution à des projets. Bien que la décentralisation de l'espace dans lequel se trouve GitHub soit une bonne chose d'une part, nous reculons en termes de facilité de soumission de problèmes ou de correctifs.

1. Comment veulent-ils utiliser cette fonctionnalité ?

La fédération résout le problème mentionné ci-dessus, car peu importe l'instance ou la plate-forme sur laquelle se trouve l'utilisateur, il peut simplement extraire un projet distant et y contribuer à partir de sa propre instance, en utilisant son propre compte local.

D'une manière ou d'une autre, GitHub ne m'a envoyé aucun e-mail de notification concernant les nouveaux commentaires ici, je les ai complètement manqués.

Quoi qu'il en soit, je continue à jouer en arrière-plan, en ce moment je suis aux prises avec le xorm et le chargement impatient.

J'ai:

type Identity struct {
  ID          int64 `xorm:"pk autoincr"`
  UserName    string
  DisplayName string
}

type User struct {
  ID          int64 `xorm:"pk autoincr"`
  Slug        string // LowerName
  IdentityId  int64 `xorm:"NOT NULL DEFAULT 0"`
  Identity    Identity `xorm:"-"`
}

Comment puis-je faire en sorte que e.Get(&User{Slug: slug}) charge automatiquement (?) le Identity donné par IdentityId ?

Je ne pense pas que cela fonctionnera. Je pense que xorm ne peut faire que l'inverse, c'est-à-dire que si Identity avait une colonne UserID , xorm pourrait remplir une tranche Identities dans User .

Si xorm est suffisamment égal à gorm, vous devriez simplement pouvoir précharger la colonne Identités pour que cela se produise. En SQL normal, ce serait un JOIN, donc http://gobook.io/read/gitea.com/xorm/manual-en-US/chapter-05/5.join.html devrait vous aider.

Quelque chose comme l'échantillon

engine.Table("user").Alias("u").
    Join("INNER", []string{"group", "g"}, "g.id = u.group_id").
    Join("INNER", "type", "type.id = u.type_id").
    Where("u.name like ?", "%"+name+"%").Find(&users, &User{Name:name})

Devrait faire l'affaire selon la doc.

Hmm, pour mon problème, avoir une liste d'identités n'aide pas.
Et malheureusement, la Join-Approach ne fonctionne pas non plus.

J'ai regardé un peu plus dans la base de code et j'ai trouvé que Repository a un Owner *User qui semble chargé manuellement à l'aide d'une fonction GetOwner , j'ai appliqué le même modèle à mon code maintenant. :)

J'ai donc nettoyé mon référentiel local, validé et poussé une version brouillon de la division utilisateur/identité qui fonctionne pour afficher un profil d'utilisateur local, par exemple localhost:8080/user1. :) Voir https://github.com/criztovyl/gitea/commit/d0f24f7919d15ee481f5eae7ec6131ff369eaa66
Pour l'instant cela ne fonctionne que pour les utilisateurs, les organisations ne fonctionnent pas encore.
Ce n'est pas beaucoup, mais c'est quelque chose. :)

En supprimant toute la viande dont disposent les organisations, la page de profil de l'organisation fonctionne désormais également. Voir https://github.com/criztovyl/gitea/compare/d0f24f7...3901206bc.

Mon code est plutôt exploiteur, ce n'est rien de définitif. :)

Pourquoi ne pas ajouter deux colonnes à la table des utilisateurs, is_local , et remote_url (peut-être domain aussi, bien que toutes les instances de gitea ne soient pas hébergées dans le dossier principal d'un domaine spécifique, d'où pourquoi Je suis allé avec romain_url ) ? De cette façon, une table supplémentaire et les jointures ne sont pas nécessaires.

Ce n'est pas la première fois que quelqu'un le suggère, j'y ai pensé aussi.
Mais je crains (ed) que cela puisse facilement conduire à comparer accidentellement un utilisateur par nom d'utilisateur uniquement, ce qui est invalide car vous devez (dans ce cas spécifique) comparer les trois is_local , remote_url et username (peut être optimisé en comparant simplement remote_url et username lorsque remote_url = "" signifie is_local ).
Une autre préoccupation serait de développer la table des utilisateurs et avec elle, par exemple, l'index pour lower_name , qui doit maintenant être un index combiné de remote_url et lower_name . (D'un autre côté, on pourrait également définir lower_name uniquement pour les utilisateurs locaux... hmm.)

Je préfère le authn/identity-split parce que je pense que c'est plus propre à mettre en œuvre. (Parce que l'identité est un nouveau concept, il ne devrait pas arriver de comparer uniquement des noms d'utilisateur.)
Mais je suppose que je devrais me décider à nouveau, maintenant que je peux voir à quel point l'introduction de la scission est complexe. :)
Je suis un peu naïf parfois. ^^

@criztovyl il y a des cas où remote_url ou domain (sub domain) changent, peuvent changer aussi

• https://mydownmain.com/gitea <--- initialement
• https://gitea.mydownmain.com <--- déplacé vers le sous-domaine
• https://source.mydownmain.com <--- voulait un nom générique
• https://git.mydownmain.com <--- voulait enfin la simplicité

comme vous le savez, nommer les choses est difficile

Essayer aussi de comprendre ce qui suit

• Et si je perdais mon domaine par exemple ? ou le nom doit changer pour des raisons légales, ou je viens de vendre mon domaine, cela signifie-t-il que je ne pourrai pas contribuer aux projets sur lesquels je travaillais auparavant ?
• Prendra-t-il en charge l'utilisation de username & email ?
• Comme vous le savez, j'ai également la possibilité de changer mon nom d'utilisateur ou d'utiliser un e-mail pour me connecter plutôt qu'un nom d'utilisateur, comment cela s'intègre-t-il dans ce que vous proposez

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

Tout le monde s'oppose au racisme, par exemple - depuis 2019, github, bitbucket et gitlab bloquent les utilisateurs en fonction de leur situation géographique perçue - https://archive.today/U1R2L . Avec l'énorme vague de manifestations BLM, ce n'est pas un bon moment dans l'histoire pour soutenir le racisme dans la communauté du logiciel. Je ne parle qu'en mon propre nom, en tant qu'utilisateur de gitea sur https://codeberg.org . Ceci est publié sous https://codeberg.org/Codeberg/Community/issues/142 , bien que je pense que cela devrait devenir un problème indépendant chez Codeberg. La discussion là suggère _some_ intérêt à Codeberg.

2. Why they need this feature?

À cause de la tyrannie de la convenance (Keye 2009) (Wu 2018) . Les fonctions de réseau social en ligne de github/bitbucket/gitlab sont extrêmement puissantes. Tapez '@' et quelques caractères, et il y a de fortes chances que vous soyez invité à entrer l'ID utilisateur de la personne que vous voulez parmi une grande partie de la communauté des logiciels libres. C'est efficace, public (par défaut), et la personne pingée peut répondre ou ignorer le problème sans avoir à nettoyer sa boîte mail.

Mais https://codeberg.org et d'autres serveurs de référentiel git non racistes n'ont pas encore de fédération de type ActivityPub. C'est l'une des raisons pour lesquelles les utilisateurs de github sont dissuadés de migrer vers des serveurs communautaires : la _tyrannie de la commodité_ est que les connexions sociales faciles dans la communauté mondiale n'existent pas - _encore_ - sur des serveurs de petite communauté.

En d'autres termes, la fonctionnalité est nécessaire pour stocker des documents éphémères savants sur des serveurs indépendants des serveurs d'entreprise centralisés, secrets et racistes (à partir de 2019/2020, voir ci-dessus).

3. How they want to use this feature?

Pour les réseaux sociaux axés spécifiquement sur le développement de logiciels au sein de la communauté ouverte de développeurs de logiciels (principalement des logiciels libres).

Verrouillage de ce fil car nous avons maintenant reçu une grande quantité de commentaires sur les questions ci-dessus et maintenant, quiconque travaille sur ce sujet disposera de ces informations qu'il pourra analyser.