[02:10:25]
<Yunohost Git/Infra notifications> [searxng_ynh] yalh76 merged [pull request #382](https://github.com/YunoHost-Apps/searxng_ynh/pull/382): Upgrade to v2025.03.29
[02:10:25]
<Yunohost Git/Infra notifications> [searxng_ynh] yalh76 deleted branch ci-auto-update-2025.03.29
[02:10:25]
<Yunohost Git/Infra notifications> [searxng_ynh] github-actions[bot] opened [pull request #383](https://github.com/YunoHost-Apps/searxng_ynh/pull/383): Upgrade master from testing
[02:10:29]
<Yunohost Git/Infra notifications> [searxng_ynh] yalh76 opened [pull request #384](https://github.com/YunoHost-Apps/searxng_ynh/pull/384): Upgrade to v2025.03.29
[02:11:36]
<Yunohost Git/Infra notifications> [piped_ynh] yalh76 merged [pull request #196](https://github.com/YunoHost-Apps/piped_ynh/pull/196): Upgrade to v2025.03.30
[02:11:37]
<Yunohost Git/Infra notifications> [piped_ynh] yalh76 deleted branch ci-auto-update-2025.03.30
[02:11:50]
<Yunohost Git/Infra notifications> [piped_ynh] yalh76 opened [pull request #197](https://github.com/YunoHost-Apps/piped_ynh/pull/197): Upgrade to v2025.03.30
[02:53:58]
<Yunohost Git/Infra notifications> [searxng_ynh] yalh76 merged [pull request #384](https://github.com/YunoHost-Apps/searxng_ynh/pull/384): Upgrade to v2025.03.29
[02:54:01]
<Yunohost Git/Infra notifications> [searxng_ynh] yalh76 merged [pull request #383](https://github.com/YunoHost-Apps/searxng_ynh/pull/383): Upgrade master from testing
[08:37:31]
<Yunohost Git/Infra notifications> [apps] yunohost-bot opened [pull request #2898](https://github.com/YunoHost/apps/pull/2898): Add Guppe to wishlist
[08:37:32]
<Yunohost Git/Infra notifications> [apps] yunohost-bot labeled Wishlist on [pull request #2898](https://github.com/YunoHost/apps/pull/2898): Add Guppe to wishlist
[10:02:17]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/524#issuecomment-2765753032) on [issue #524](https://github.com/YunoHost-Apps/synapse_ynh/issues/524) homeserver.py --generate-config error: And now can you try again an upgrade with this command:
sudo yunohost app upgrade synapse -u https://github.com/Yuno...
[10:02:34]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/524#issuecomment-2765753032) on [issue #524](https://github.com/YunoHost-Apps/synapse_ynh/issues/524) homeserver.py --generate-config error: And now can you try again an upgrade with this command:
sudo yunohost app upgrade synapse -u https://github.com/Yuno...
[10:10:20]
<Yunohost Git/Infra notifications> [nextcloud_ynh] rodinux pushed 1 commit to oldstable: Update manifest.toml version 29.0.14 ([b6b111e4](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/b6b111e42e70f5778b2e5468dea344a1d86624d9))
[11:13:58]
<Yunohost Git/Infra notifications> [nextcloud_ynh] rodinux pushed 75 commits to oldstable ([93e5322b83d6...4457c4d6ac5e](https://github.com/YunoHost-Apps/nextcloud_ynh/compare/93e5322b83d6...4457c4d6ac5e))
[11:13:59]
<Yunohost Git/Infra notifications> [nextcloud_ynh/oldstable] Testing (#789) * move function to common.sh (#764) * move function to common.sh * Update config * add default_phone_... - Alexandre Aubin
[11:14:00]
<Yunohost Git/Infra notifications> [nextcloud_ynh/oldstable] Merge branch master into oldstable - Robles Rodolphe
[11:14:00]
<Yunohost Git/Infra notifications> [nextcloud_ynh/oldstable] Testing (#793) - eric_G
[12:19:38]
<Yunohost Git/Infra notifications> [appgenerator] felurx opened [pull request #15](https://github.com/YunoHost/appgenerator/pull/15): Fix call to ynh_script_progression in upgrade.j2
[12:23:17]
<Yunohost Git/Infra notifications> [nextcloud_ynh] rodinux pushed 1 commit to oldstable: Update upgrade cleaning ([541ba53f](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/541ba53fbbfcd8b7fe7951d93cdb13ffcc597f72))
[12:27:25]
<Felix 3> What are the conditions for being a maintainer for YNH stuff? I'd like to help with the app generator, since I keep on noticing small bugs and apparently no one has had the time to look at my other PR in 4 weeks.
EDIT: https://github.com/YunoHost/project-organization/blob/master/yunohost_project_organization.md describes it very well, oops!
[12:29:00]
<Yunohost Git/Infra notifications> [nextcloud_ynh] rodinux pushed 1 commit to oldstable: Update upgrade cleaning ([e86192d0](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/e86192d03196acc9021b7fe3ec063f52421be6e3))
[12:34:12]
<Felix 3> I think I might be a few steps off from becoming a Regular Contributor. In this case, is there someone I can/should ping who can take a look at my PRs?
(Just for clarity: Absolutely no hard feelings about the PRs not getting attention, I understand that people have lives and are doing stuff on their free time. It's just that I myself sometimes need a little push to do things, and I think my PRs are small enough that it should be minimal effort to merge them.)
[12:44:44]
<Yunohost Git/Infra notifications> [nextcloud_ynh] rodinux pushed 1 commit to oldstable: Update manifest.toml keep only bullseye available ([855defe7](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/855defe7e406499b71ffe291797b68514914a79b))
[15:40:33]
<m606> hello, in upgrade script, if at install I had set a setting with `ynh_app_setting_set` bound to a `.env` file in config_panel.toml:
1. is current app setting automatically saved and reapplied to my `.env` file which would overwrite the previous one?
1. should I `ynh_app_setting_get` and `ynh_app_setting_set` this setting explicitly in the upgrade script so that it got reapplied to the `.env` file (i.e. new `ynh_config_add --template=".env" --destination="$install_dir/.env"`)
1. should I only keep current `.env` with `ynh_setup_source --dest_dir="$install_dir" --full_replace --keep=".env"` and not need to think about setting ?
[15:42:26]
<m606> `.env` file contains something like `MY_SETTING=__MY_SETTING__`
[15:47:38]
<m606> hello, in upgrade script, if at install I had set a setting with `ynh_app_setting_set`, bound to a `.env` file in config_panel.toml:
1. is current app setting automatically saved and reapplied to my `.env` file which would overwrite the previous one?
1. should I `ynh_app_setting_get` and `ynh_app_setting_set` this setting explicitly in the upgrade script so that it got reapplied to the `.env` file (i.e. new `ynh_config_add --template=".env" --destination="$install_dir/.env"`)
1. should I only keep current `.env` with `ynh_setup_source --dest_dir="$install_dir" --full_replace --keep=".env"` and not need to think about setting ?
[15:55:37]
<m606> > <@m606:matrix.org> hello, in upgrade script, if at install I had set a setting with `ynh_app_setting_set` bound to a `.env` file in config_panel.toml:
> 1. is current app setting automatically saved and reapplied to my `.env` file which would overwrite the previous one?
> 1. should I `ynh_app_setting_get` and `ynh_app_setting_set` this setting explicitly in the upgrade script so that it got reapplied to the `.env` file (i.e. new `ynh_config_add --template=".env" --destination="$install_dir/.env"`)
> 1. should I only keep current `.env` with `ynh_setup_source --dest_dir="$install_dir" --full_replace --keep=".env"` and not need to think about setting ?
actually I'd rather consider only options 1 or 2 so that when`.env` gets updates from upstream I only have to edit .env template file and not upgrade script.
[16:09:53]
<m606> > <@m606:matrix.org> actually I'd rather consider only options 1 or 2 so that when`.env` gets updates from upstream I only have to edit .env template file and not upgrade script.
I think I've got an answer there https://github.com/YunoHost/issues/issues/1973
option 1 seems a yet open question for packaging V3, so i'll be heading to option 2
[16:12:17]
<Aleks (he/him/il/lui)> (not sure to fully understand the context / scenario, not sure to understand option 2, calling `ynh_app_setting_get` + `ynh_app_setting_set` doesn't really do anything ? and it shouldnt be necessary because settings are loaded as env variables anyway ?)
[16:13:11]
<Aleks (he/him/il/lui)> if your `.env` file is a template with `__MY_SETTING__` then during upate you just want to call `ynh_config_add --template=".env" --destination="$install_dir/.env"` yeah ?
[16:15:57]
<m606> > <@Alekswag:matrix.org> (not sure to fully understand the context / scenario, not sure to understand option 2, calling `ynh_app_setting_get` + `ynh_app_setting_set` doesn't really do anything ? and it shouldnt be necessary because settings are loaded as env variables anyway ?)
to try making it clearer:
`install` has
```
clear_interval=300
ynh_app_setting_set --key=clear_interval --value=$clear_interval
ynh_config_add --template=".env" --destination="$install_dir/.env"
```
`.env` has
```
CLEAR_INTERVAL=__CLEAR_INTERVAL__
```
`config_panel.toml` has
```
[main.administration.clear_interval]
ask.en = "Expired passwords clear interval (seconds)"
ask.fr = "Délai du contrôle périodique des mots de passes expirés (secondes)"
type = "number"
bind = "CLEAR_INTERVAL:__INSTALL_DIR__/.env"
help.en = "Default setting = 300 (5mn)"
help.fr = "Réglage par défaut = 300 (5mn)"
```
[16:19:06]
<m606> > <@Alekswag:matrix.org> if your `.env` file is a template with `__MY_SETTING__` then during upate you just want to call `ynh_config_add --template=".env" --destination="$install_dir/.env"` yeah ?
if after install, an app admin changes value of $clear_interval via the config panel, if I understand well how `bind` works the `.env` file will be get updated with new value.
Now during app upgrade script, if I do as you suggest, what would be the value of $clear_interval ? default package value or last value saved by admin ?
[16:20:29]
<Aleks (he/him/il/lui)> naively i would say that everything is fine as long as you do re-call `ynh_config_add` during the upgrade (assuming that when editing the value via th econfig panel, it both modifies the file and the setting)
[16:25:57]
<m606> > <@Alekswag:matrix.org> naively i would say that everything is fine as long as you do re-call `ynh_config_add` during the upgrade (assuming that when editing the value via th econfig panel, it both modifies the file and the setting)
oh ok. So i'll try that way.
[16:25:58]
<m606> tha,ks
[16:50:32]
<Felix 3> https://doc.yunohost.org/en/packaging_config_panels#the-bind-statement confirms that "[...] values are [...] read/written from/to the app's settings file" and https://doc.yunohost.org/en/packaging_scripts#variables-available-in-a- confirms that "During other scripts, all app settings are also loaded and automatically available." 👍️
[16:53:41]
<Felix 3> Just to check my understanding: If an admin edits the config file (.env for example) by hand with a text editor, all changes made this way would be lost during an upgrade, right?
[17:00:54]
<m606> > <@felurx:matrix.org> Just to check my understanding: If an admin edits the config file (.env for example) by hand with a text editor, all changes made this way would be lost during an upgrade, right?
that's my understanding too, in case that change was never mapped to settings.yaml at some point (if that setting is bound to the file in the config panel, that you edited manually the file, but then save again normally in the config panel - i guess that would update settings.yaml).
Then you may ask the relevance for the admin to edit manually such file if it can be edited in the config panel (packagers being encouraged to create config panels for settings admin may like to tweak).
For some cases, you may also use `--keep` param as in `ynh_setup_source --dest_dir="$install_dir" --full_replace --keep=".env"` during upgrade script so that old `.env` is not overwritten during the upgrade process.
[17:10:40]
<m606> > <@felurx:matrix.org> https://doc.yunohost.org/en/packaging_config_panels#the-bind-statement confirms that "[...] values are [...] read/written from/to the app's settings file" and https://doc.yunohost.org/en/packaging_scripts#variables-available-in-a- confirms that "During other scripts, all app settings are also loaded and automatically available." 👍️
> During other scripts, all app settings are also loaded and automatically available.
Yes, this indeed suggests Aleks' guess, i.e. that apps settings.yaml are transferred from OLD app version to NEW app version during upgrade, even though I feel it could be more explicit. I may update it after I see the mechanism working properly.
[17:10:55]
<Felix 3> Thanks!
I'm currently packaging a PHP app and am breaking my head a bit about configs, config panels and app settings... I did either miss one of the puzzle pieces here (app settings being available as environment variables and being set from the config panels) or how they fit together, which is kind of nice.
[17:12:26]
<Felix 3> Yeah, I completely agree, this could/should be made more obvious for new packagers. (I don't feel confident enough in my understanding to edit the docs myself, though 😅)
[17:18:30]
<Felix 3> Ah: According to https://doc.yunohost.org/en/packaging_apps_helpers_v2.1#keeping-track-of-manual-c , manual changes are noticed and the file is backed up in that case. (But I think the changes would still be made uneffective until manually restored by the admin)
[17:23:16]
<m606> > <@felurx:matrix.org> Thanks!
> I'm currently packaging a PHP app and am breaking my head a bit about configs, config panels and app settings... I did either miss one of the puzzle pieces here (app settings being available as environment variables and being set from the config panels) or how they fit together, which is kind of nice.
yes settings & config panel has its own logic and takes some time to assimilate. the basic scheme is that all default settings, or custom settings declared in scripts are saved into a `settings.yaml` file stored in an $app-related folder (not sure anymore by heart which one). Those settings can be bound to files, so that their value can be both used/edited easily in script as well as by the $app (via a config file). If you need more than just "copy/pasting" a value, you can set custom getter/setter (bash functions) in `scripts/config` to transform the input/output before saving/showing it.
Basically i believe it makes sense suggesting doc edits after you got in troubles to help future packagers (or yourself in a few months). But yes only on things you do have verified.
[17:37:01]
<Yunohost Git/Infra notifications> [piped_ynh] yalh76 merged [pull request #197](https://github.com/YunoHost-Apps/piped_ynh/pull/197): Upgrade to v2025.03.30
[17:39:48]
<m606> > <@felurx:matrix.org> Ah: According to https://doc.yunohost.org/en/packaging_apps_helpers_v2.1#keeping-track-of-manual-c , manual changes are noticed and the file is backed up in that case. (But I think the changes would still be made uneffective until manually restored by the admin)
indeed, it is backed up to [that folder](https://github.com/YunoHost/yunohost/blob/8280926cc858acb69be3b243c1b4a901d715431f/helpers/helpers.v2.1.d/backup#L267), but differing settings are not resolved automatically. the new config will prevail.
[17:41:51]
<Yunohost Git/Infra notifications> [synapse_ynh] gtdm [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/524#issuecomment-2766931555) on [issue #524](https://github.com/YunoHost-Apps/synapse_ynh/issues/524) homeserver.py --generate-config error: https://paste.yunohost.org/raw/exemonaqug
[17:42:03]
<Yunohost Git/Infra notifications> [synapse_ynh] gtdm [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/524#issuecomment-2766931555) on [issue #524](https://github.com/YunoHost-Apps/synapse_ynh/issues/524) homeserver.py --generate-config error: No error during the upgrade: https://paste.yunohost.org/raw/exemonaqug
[18:02:00]
<Felix 3> I guess the biggest question/problem I have left is how to update the distributed config file while allowing/encouraging admins to configure stuff by hand if they need/want to.
(The app I'm packaging has a ton of options one might want to modify, but I don't think it's realistic, or a good idea, to put them all in config panels.)
I currently have two files, `config.inc.php` for customization and stuff, and a `config-ynh.inc.php` that does the behind-the-scenes stuff. I was planning to let the admin edit the `config` (by hand or via config panel) and not touch that during upgrades, while reserving the `config-ynh` for "internal" use and overwriting it on upgrade.
This has the problem that if I want to edit the comments or structure of `config`, I don't really have a way to do so, since the admin may have edited it by hand.
The only workaround I can think of would be to provide a block text field for custom options instead of letting the admin edit the config files, but that feels a bit annoying too.
How do other packages deal with this? Do you just accept that you have to decide between allowing edits by the admin and being able to change the file via updates?
[18:04:04]
<Yunohost Git/Infra notifications> yalh76 deleted repository solidtime_ynh https://github.com/YunoHost-Apps/solidtime_ynh
[18:11:10]
<Yunohost Git/Infra notifications> [nextcloud_ynh] rodinux pushed 1 commit to oldstable: Update manifest.toml Just to be sure the CI accept running ([ce6e9ebe](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/ce6e9ebee74b3eb2ec0032824c047e3555526086))
[19:48:50]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/524#issuecomment-2767241417) on [issue #524](https://github.com/YunoHost-Apps/synapse_ynh/issues/524) homeserver.py --generate-config error: Ok so the issue seem solved now.
[20:06:54]
<m606> I don't really have in mind the context where it wouldn't be a good idea to put them in config panel if admins can realistically be willing to customize those. You've probably noticed that you can organize config panel in subsections, some optional, some compulsory, etc., to make it clearer for the admins.
Just keep in mind that for things far behind the scene, most of the admins won't be digging it, so I don't know thinking too much on that makes sense - admins will still be able to raise the issue if this happens to be missing to some. In those cases I would just set the default average value that should match most of the needs.
Because yes, what you are trying to do can be difficult to maintain while ensuring compatibility from a packager/maintainer perspective, i.e. prone to errors.
I haven't faced such case myself where I would feel the need to create 2 distinct editable sets of settings. In the few packages I have created so far, I have been drawing a common sense/arbitrary line between what would be interesting to have in config panel and what can remain as default config. You can always make your package evolve for future needs (for this try to think in terms of ease of maintaining future downward compatibility), and anyway you don't know how popular can be your package (except maybe if you are packaging one of the most wished ones in the wishlist - which doesn't mean if should be poor of course, but just that you may not need to dive in all very specific details at first).
As for multiline config block in the config panel, I [made one recently](https://github.com/YunoHost-Apps/marl_ynh/blob/master/config_panel.toml) if you want to look at an example (make sure to check the associated `scripts/config` file). It aims at getting one URL per line, the whole URL block being then converted into a bash array in a custom setter and eventually written in a JS config file.
[21:49:30]
<Yunohost Git/Infra notifications> oleole39 transferred repository passed_ynh: Share a password with someone securely. https://github.com/YunoHost-Apps/passed_ynh
[22:18:28]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 10 pending update PRs
- 10 new apps PRs
- 14 failed apps updates: appflowy, jenkins, khatru-pyramid, kiwix, languagetool, lemmy, localai, misskey, ofbiz, opencloud, phpldapadmin, pixelfedglitch, snweb, stremio
See the full log here: https://paste.yunohost.org/raw/hetogajaqe
[22:39:13]
<m606> CI failing due to strange error:
> 276 ERROR This app requires YunoHost >= 12.0.9 but current installed version is 11.2.30.2
https://ci-apps-bullseye-dev.yunohost.org/ci/job/23438
[22:40:13]
<m606> > <@m606:matrix.org> CI failing due to strange error:
> > 276 ERROR This app requires YunoHost >= 12.0.9 but current installed version is 11.2.30.2
> https://ci-apps-bullseye-dev.yunohost.org/ci/job/23438
or bullseye does not support 12x ?
[22:41:42]
<rodinux> Is the CI for bullseye which does not support if in the manifest `>=12.0.9` is a rule
[22:42:28]
<rodinux> https://github.com/YunoHost-Apps/passed_ynh/blob/d4908aff65d059ab92e9334c95e98d5cfdb3d207/manifest.toml#L21
[22:51:42]
<Felix 3> Hm, you do have a point, I might be overthinking stuff...
Thing is, the tool I'm packaging is pretty flexible and just has [a true ton of variables you can set](https://github.com/meeting-room-booking-system/mrbs-code/blob/main/web/systemdefaults.inc.php), somewhere around 200 distinct settings (334, but around a third of them are related to auth and stuff, plus some 50 for default room settings). For context, it's a room/resource booking thing ([MRBS](https://mrbs.sourceforge.io/)).
Some of those 200 settings are going to be relevant to many users and definitely worth a config panel entry (like the displayed org name, selectable time ranges or some display stuff), some settings won't be relevant for anyone, but I feel like many users will want some specific ones and that that set is going to vary wildly between users. Like, some are going to want emails for these and those kinds of events, some users will want this and that kind of booking policy, etc
I don't think I'll have the time (or, frankly, can be bothered) to add all of the last category, and it would probably be a bit overwhelming for an admin too. Oh, and then there also are vocabulary overrides (like making it talk about "resources" instead of "rooms") that have to be done per locale, I don't even know how I'd put that into a config panel.
Long story short, I will of course try to make the most common and useful settings available through config panels. But I'd still like to enable admins who are technically inclined to edit a config file to do so if they want to use the full range of flexibility of the tool.
[22:52:30]
<m606> > <@rodinux:matrix.org> Is the CI for bullseye which does not support if in the manifest `>=12.0.9` is a rule
Ok thanks. Well I inherited that value from `example_ynh` app's manifest. is that better to make it compatible with earlier versions? It uses helpers 2.1, but appart from that I'm unsure of what prevents it to be compatible with earlier core version.
[22:54:53]
<rodinux> I am not sure bullseye will accept helpers 2.1...
[22:56:32]
<rodinux> If you want use it with compatibility bullseye, must be helprers v2
[22:57:34]
<m606> ok thanks. Well I personnally don't mind, I'll leave it like this then.
[22:59:33]
<m606> > <@felurx:matrix.org> Hm, you do have a point, I might be overthinking stuff...
>
> Thing is, the tool I'm packaging is pretty flexible and just has [a true ton of variables you can set](https://github.com/meeting-room-booking-system/mrbs-code/blob/main/web/systemdefaults.inc.php), somewhere around 200 distinct settings (334, but around a third of them are related to auth and stuff, plus some 50 for default room settings). For context, it's a room/resource booking thing ([MRBS](https://mrbs.sourceforge.io/)).
> Some of those 200 settings are going to be relevant to many users and definitely worth a config panel entry (like the displayed org name, selectable time ranges or some display stuff), some settings won't be relevant for anyone, but I feel like many users will want some specific ones and that that set is going to vary wildly between users. Like, some are going to want emails for these and those kinds of events, some users will want this and that kind of booking policy, etc
> I don't think I'll have the time (or, frankly, can be bothered) to add all of the last category, and it would probably be a bit overwhelming for an admin too. Oh, and then there also are vocabulary overrides (like making it talk about "resources" instead of "rooms") that have to be done per locale, I don't even know how I'd put that into a config panel.
>
> Long story short, I will of course try to make the most common and useful settings available through config panels. But I'd still like to enable admins who are technically inclined to edit a config file to do so if they want to use the full range of flexibility of the tool.
urg, yes that's a "thorough" config file...
[23:03:31]
<Felix 3> I think I have three main options here:
1) Hand over control of the config file to the admin and don't overwrite it during upgrades (which would easy enough, but then I can't improve comments/structure for existing installs)
2) Hack up something to give the admin a text area they can put arbitrary settings in (should also be doable, especially if I give up on prettiness and just put that in a third config file that I include from the main config 🙈)
3) Give up on giving admins the option to use settings that I don't explicitly handle (which would be easiest, but I don't wanna :D)
[23:04:59]
<Aleks (he/him/il/lui)> in the yunohost spirit, i guess you're supposed to editorialize a bit and only expose the important "high-level" settings which people are likely to be willing to tweak
[23:06:20]
<Aleks (he/him/il/lui)> eg all the db options and mail options are just low-level stuff that are supposed to be handled automatically by yunohost and there's no point making those configurable by the config panel
[23:08:01]
<Felix 3> Option 1 has the advantage that if I add a config panel entry for something an admin has already configured by hand, it's all handled seamlessly too (since the panel will just load/edit the line the admin has created) 🤔
Also, there's a clear line between the "normal" stuff (using the panel) and "advanced" things (editing the config file).
[23:10:13]
<Felix 3> Yea, true. I don't have any trouble with those, it's the booking/mailing policy stuff that *some* users will want that's giving me headaches 😅
[23:14:18]
<Aleks (he/him/il/lui)> zblerg it feels like building a webadmin ui for an app that doesnt have any x_x
[23:17:40]
<Felix 3> I think I prefer Option 1, and will of course be endlessly annoyed by my decision the moment I want to edit some comment or whatever
Are there any obvious situations in which I want to edit the config file of existing installations, beyond what can be done with the settings / config panel / ynh_write_var_in_file stuff? (Also, since LDAP, auth, etc are in a separate file, touching those won't be an issue either)
In any case, I think I'll have a night of sleep over the matter 😴
[23:21:57]
<m606> the thing is that even if you go for option 1, it would require work to replace some of the defaults value of upstream config file with YNH templates tags (things like `__TIMEZONE__`, DB stuff pointed by Aleks, etc.) 🤔
[23:52:08]
<Yunohost Git/Infra notifications> [apps] oleole39 opened [pull request #2899](https://github.com/YunoHost/apps/pull/2899): add PassED to catalog
[23:53:11]
<Yunohost Git/Infra notifications> [apps] oleole39 edited [pull request #2899](https://github.com/YunoHost/apps/pull/2899): add PassED to catalog
[23:53:27]
<Yunohost Git/Infra notifications> [apps] oleole39 edited [pull request #2899](https://github.com/YunoHost/apps/pull/2899): add PassED to catalog