Hello,
Do you know if the stable version will be released in days / weeks / months ?
Thank you 
Mise à jour effectuée sans encombre.
Je n’utilise pas les groupes et peu de permissions différentes sur mon serveur. L’interface est claire en tout cas!
1 Like
Possibly in a few days / weeks, yes… The more feedback we get, the faster we can validate the release with as few issues as possible
Hi,
Upgrade went smoothly 
Thanks !
I added the visitors on all_users groups in both command line and webadmin 
Ludovic
1 Like
Hi, it seems it’s my first post here, so hello everybody 
Here is the output I have from launching the command:
root@garnet:/home/admin# curl https://install.yunohost.org/switchToTesting | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 459 100 459 0 0 5010 0 --:--:-- --:--:-- --:--:-- 5043
----
Patching sources.list to enable testing repository...
----
----
Running 'apt-get update'
----
Ign:1 http://ftp.debian.org/debian stretch InRelease
Hit:2 http://security.debian.org stretch/updates InRelease
Hit:3 http://ftp.debian.org/debian stretch-updates InRelease
Hit:4 http://ftp.debian.org/debian stretch Release
Hit:5 http://forge.yunohost.org/debian stretch InRelease
Reading package lists... Done
----
Running 'apt-get dist-upgrade'
----
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
etckeeper iproute
Use 'sudo apt autoremove' to remove them.
The following packages will be upgraded:
moulinette ssowat yunohost yunohost-admin
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.2 MB of archives.
After this operation, 672 kB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.
root@garnet:/home/admin# curl https://install.yunohost.org/switchToTesting | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 459 100 459 0 0 4379 0 --:--:-- --:--:-- --:--:-- 4413
----
Patching sources.list to enable testing repository...
----
----
Running 'apt-get update'
----
Ign:1 http://ftp.debian.org/debian stretch InRelease
Hit:2 http://ftp.debian.org/debian stretch-updates InRelease
Hit:3 http://security.debian.org stretch/updates InRelease
Hit:4 http://forge.yunohost.org/debian stretch InRelease
Hit:5 http://ftp.debian.org/debian stretch Release
Reading package lists... Done
----
Running 'apt-get dist-upgrade'
----
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
etckeeper iproute
Use 'sudo apt autoremove' to remove them.
The following packages will be upgraded:
moulinette ssowat yunohost yunohost-admin
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.2 MB of archives.
After this operation, 672 kB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.
See, at then end it automatically aborts, so I had to apt update/upgrade by hand. After this migration seemed ok, but I have this message in admin backend:
Unable to retrieve the feed: https://yunohost.org/security.rss. An extension may prevent your browser from executing this request (or the website may be down).
Weird error happening updating discourse…
https://paste.yunohost.org/ivogibihij.coffeescript
EDIT: nevermind, I removed/re-added all_users and visitors permissions and it worked (now I understand the release notes of the latest beta 
)
Hi guys
is there a documentation or anything similar about the new permission system ?
Also, how the migration is going to be for the apps that don’t use that permission system yet ?
EDIT:
Looks like the answer is into that PR https://github.com/YunoHost/yunohost/pull/797
I wasn’t there by the time of that PR, and I’m not so relieved actually…
Found the doc as well, https://github.com/YunoHost/doc/blob/group-and-permissions/groups_and_permissions.md
What’s worry me especially is that the doc says :
Applications scripts should absolutely NOT mess up with any already-existing app accesses
Public/private access is not always just about skipped_uris "/", there’s many specific access, like an admin panel or other stuff.
We can’t expect that users are going to play with all the specific permissions for an app when willing to turn off or on the public access for an app. It as to be simple.
So actions scripts dedicated to that purpose have to be still available for the users willing to turn on or off a public access without complication.
EDIT 2:
Before releasing that testing, a clear announce has to be done to all packagers to explain how to modify their apps with examples and clear explanations.
I’m really worried that we’re going to break a lot of apps if there’s no proper warning about that new feature. I wasn’t aware of it myself.
Do we have a bot on Github that can automagically open an issue in the apps’ repos if scripts contain anything related to accesses? (Now that I wrote it, I think it will involve all apps actually)
Exactly @tituspijean, if not almost every apps.
If I understand well, for apps with a simple skipped_uris "/" it shouldn’t be a problem. But for all apps with API access, admin panel or public download links, it’s going to be a problem.
Pretty much everything is backward compatible, so basically all install and other scripts will keep working as they do right now (modulo depreciationg warning), and if they don’t then that’s a bug that should be fixed.
As far as I remember, the only not-backward compatible thing is the use of protected uris, in the sense that even when being logged-in you still won’t have access to the protected uris (so that’s kinda conservative). The affected apps are apparently : lstu, lufi, dotclear, lektor, bozon, and lutim.
Admin panels are expected to be handled by a specific permission. Typically you would define such a permission with something like :
ynh_permission_create --permission "admin" --url "/admin" --allowed "$admin_user"
which controls accesses to https://domain.tld/app/admin. Then the instance’s admin can add/remove accesses to this permission from the webadmin interface, just like it does for the main permission which controls access to /app. (Also, if I remember correctly, a user has to be authorized for /app/ to be able to access /app/admin.)
Not sure what you’re thinking about, but right now it’s “just” about : going into Users > Manage permissions and groups, then adding / removing the permission to the ‘Visitors’ group and that’s it. Then visitors will be able to access (or not) to /app (but not to /app/admin if it’s controlled through a diferent permission)
There have been test batches using the unstable CI to validate that there was no regression (at least from the CI point of view) though I didn’t re-ran a batch of test following the release of the testing and the next iterations of fixes
What I’m thinking about is that kind of thing:
That’s not obvious (my bad by the way) but here the idea is to have the links always publicly available, but not the main page of jirafeau nor its admin panel.
It would translate as 3 different permissions. But an user willing to turn the app public or private shouldn’t have to play with those 3 different permissions and know which one should be private or not.
An user that want to turn the app public or private should be able to simply ask for it, without having to know how it should work. And that exactly the purpose of the actions public_private.
Jirafeau is only one example of those permissions.
We have also that kind of situation for API for mobile apps.
Those situations are what I’m thinking about when I say that apps are going to break. The CI can’t test those things.
Again, I’m not saying that all that permission system is a bad thing, but packagers should have a proper warning and a clear explanation before that testing is released.
I quickly read the install script of all our apps tagged as “working”.
Among them, here a list of the ones which are doing non trivial things with the old permission system (not only a simple protect “/”):
I may miss some of them.
I added those that are doing something like yunohost app addaccess $app -u $admin because I was not sure if it can be a problem with the new permission system.
A new testing version has been released, which includes some important fixes:
Detailed changelog
- [fix] Match undefined function (SSOwat#151)
- [fix] Cohabitation between the old and the new permission system (SSOwat#156)
- [fix] Slapd may crash if we try to update the LDAP with no change (Moulinette#231)
- [fix] Permission url (YunoHost#871)
- [fix] DNS resolver (YunoHost#859)
- [fix] Legacy permission management (YunoHost#868, YunoHost#855)
- [enh] More informations in hooks permission (YunoHost#877)
- [i18n] Improved translations for French, Basque, Hindi, Turkish, Bengali (Bangladesh), Arabic, Hungarian, Polish, Catalan, Dutch, Portuguese, Italian, German, Swedish, Russian, Esperanto, Occitan, Nepali
Thanks so much to all the contributors 
! (Aleks, amirale qt, Bram, ButterflyOfFire, elie gavoty, Filip Bengtsson, Josué, Kay0u, ljf, Maniack, Quenti, xaloc33)
5 Likes
Bonsoir,
Dans le cadre du passage de Stretch à Buster, faudra-t’il passer par un mise à niveau de YunoHost 3.6.x à 3.7.x préalablement à la migration ?
ppr
Bonjour,
Rien n’est encore fixé il me semble, mais de toute façon il vaut mieux (si ce n’est pas obligatoire?) être à la version la plus à jour avant de faire la migration.
Nous prévoyons encore une 3.8 avant le passage à la 4.0 (Buster) afin de préparer le terrain.
Bonjour,
Merci pour ces informations.
La version stable actuelle est 3.6.x.
Est-ce que la 3.7.x testing va bientôt passer en stable ?
On verra pour la 3.8.x après avant la migration vers la 4.0.x
ppr
Nous attendons des retours ainsi que l’intégration continue des apps en testing pour passer la 3.7 en stable.
1 Like
De mon côté, je suis en testing 3.7.0.6 sur une Raspberry Pi 3 (qui n’est pas en prod’) et pour l’heure ça fonctionne avec phpMyAdmin, Rainloop et Custom Webapp (avec un CMS dedans sans Base De Données pour l’école en cette période).
Raspberry Pi qui sert à CI package check en temps normal.
ppr
1 Like
Sur le panel admin, dans la catégorie Utilisateurs, j’ai un bouton sans texte (“groups_and_permissions_manage”) qui redirige vers l’accueil de l’admin.
Le même bouton est sur le descriptif d’une application, il redirige également vers l’accueil de l’admin. Avec également un problème de string sur ce même écran, de plus les permissions pour SOGo étaient définies à “Tout le monde” en 3.6 et maintenant, d’après l’écran, en “nobody”. Est-ce normal ?
EDIT : après un clear de cache du navigateur et un redémarrage du serveur, tous les problèmes cités au dessus sont résolus