[19:16:59]
<florent> > <@titus:pijean.ovh> > tituspijean (@tituspijean:libera.chat) a rejoint le salon
>
> I absolutely did not.
Mmmm moi non plus…
[19:17:16]
<florent> (cyxae@libera.chat)
[19:30:50]
<florent> C'est ptêt déjà arrivé, mais pas récemment il me semble
[19:31:03]
<florent> Fin bon ça m'a pas l'air très grave tsé
[19:38:04]
<Aleks (he/him/il/lui)> > <@titus:pijean.ovh> Anyhow... I am currently looking at 🌈 *self-registration* 🦄.
> Are the glocal settings in `/etc/yunohost/settings.yml` automatically populated? I cannot see direct code writing to that file, I guess it's save with defaults when the config panel is loaded for a first time, or a regen-conf calls it?
u wot m8
[19:38:08]
<Aleks (he/him/il/lui)> settings.yml is handled as a yunohost config panel i believe
[19:50:15]
<Aleks (he/him/il/lui)> i guess yes, but naively i'd say that should be avoided
[19:54:35]
<Aleks (he/him/il/lui)> also imho the user self-registration thingy should be implemented as part of the new non-root portal API (https://github.com/YunoHost/yunohost/pull/1387 - still WIP :/) otherwise it becomes quickly uncomfortable that some random folks can trigger code running as root in the current API which was always designed as "don't need to be injection-free because the user triggering actions is root anyway" .. though we can prototype what it would become in the new API i guess
[19:57:37]
<Aleks (he/him/il/lui)> 😅
[20:01:30]
<Aleks (he/him/il/lui)> eeeh not sure to get what it's supposed to contain ?
[20:01:56]
<Aleks (he/him/il/lui)> ah i see
[20:02:34]
<Aleks (he/him/il/lui)> not sure why it would clog up the API to have a single file tho ?
[20:10:15]
<Aleks (he/him/il/lui)> > <@titus:pijean.ovh> mmmh... let me rephrase, what might happen if the server is slow and 10 persons try to register at the same time? my guess is that the 10 `user_subscription_register()` processes will try to open and alter `/etc/yunohost/subscriptions.yml`, and some might get a timeout.
hmmmyeah that's something to be careful about, but on the other hand the lock mechanism should be enough to prevent this from happening
[20:11:01]
<Aleks (he/him/il/lui)> > <@titus:pijean.ovh> should I split the actionsmap on that?
yeah i would tend to avoid having two endpoints of different nature on the same action
[20:19:22]
<Yunohost Git/Infra notifications> [issues] @tituspijean [commented](https://github.com/YunoHost/issues/issues/1677#issuecomment-1608187242) on [issue #1677](https://github.com/YunoHost/issues/issues/1677) Allow users to self-register (or with invitation link): Question, since I am writing the actionsmap for this. Currently yunohost user create command needs the following argum...
[20:45:48]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean pushed 1 commit to user_registration: Actions map and config panel for user registration ([59eca6b2](https://github.com/YunoHost/yunohost/commit/59eca6b2c9807875b149661e476d693577297ea8))
[20:45:50]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean created new branch user_registration
[21:02:31]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean opened [pull request #1682](https://github.com/YunoHost/yunohost/pull/1682): User registration backend
[21:02:31]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean labeled depends on other PR on [pull request #1682](https://github.com/YunoHost/yunohost/pull/1682): User registration backend
[21:04:00]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#912414495](https://gitlab.com/yunohost/yunohost/-/pipelines/912414495) failed on branch user_registration
[21:09:48]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean pushed 1 commit to user_registration: [user_registration] Fix calls to patterns ([e4f83f34](https://github.com/YunoHost/yunohost/commit/e4f83f3413d227a6d16dc9ea992f73814d386114))
[22:23:27]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#912420042](https://gitlab.com/yunohost/yunohost/-/pipelines/912420042) failed on branch user_registration