-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ynh_permission_*
helper should not be depreciated
#128
Comments
Though, would we actually need that condition if we were using packaging v2, with a |
On one hand, yes, but on the other hand, the point of declarativeness is that you're supposed to know what state to configure just by reading a static file and not having to run any epic install/update/whatever script. If we allow .1% of apps to do "stuff only in scripts" then this means we can't develop any stuff like So imho this just means that we have a shortcoming in the current packaging format, and we should keep track of it. I guess ultimately this means we should have so |
Well, For synapse it's quite specific because we have the And for this part it could be a domain managed by yunohost but it could also be anything else that the user manage somewhere else. In the case of yunohost manage it, we try to configure the |
But yes I agree with the idea of a declarative way of And as same as for this (YunoHost/issues#2245) we depreciate the |
To ensure that only the user selected as admin can access the app I use |
On some apps like
synapse
we must enable conditionally some permission. The declarative way in themanifest.toml
is great but is also limited. In some case we need more flexibility it's why we still need theses helper to manage theses cases.The text was updated successfully, but these errors were encountered: