feat(updater): Allow to define locked apps to (not) be updated

[solracsf]

Summary

In some environnements, it can be useful to "lock" apps to disallow updates by administrators for many reasons; control when updates are made, deny updates from the Web while manually forcing them on the CLI (after disable the switch), forcing an app to remain on a specific version, etc.

Actually, to accomplish a similar behavior, one must render the /apps/<app> folder unwritable by the webserver (ex.: cd /var/www/nextcloud/apps/; chmod 0750 <app>; chown -R root:www-data <app>) because if webserver can't write on the app folder, app can't be updated.

With this PR, an Administrator could publish an array of apps on config.php like:

'apps_locked' => ['user_saml', 'groupfolders', 'onlyoffice'];

And such apps couldn't be updated unless the app name is removed from the array.
We could also implement a --force switch on the CLI, but i believe that removing the app from the array could be more effective.

One question remains; if, while upgrading server to a major version (32>33) apps need update for compatibility reasons, how to handle this case effectively:

1. Deny server upgrade and ask administrator to empty the array?
2. Bypass that switch and upgrade apps nevertheless?

Please review and comment.

ToDo

• Documentation

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[CarlSchwan]

This is missing documentation in config.sample.php

[solracsf]

I'll do it when green light about a possible merge 😁

[CarlSchwan]

@AndyScherzinger what do you think about this feature :)

[AndyScherzinger]

I'd like to discuss it first, since I get the use case and motivation but think the feature solves an issue that shouldn't be there in the first place: there shouldn't be a reason not to update an app

Things I do understand in terms of version management and would agree to are:

• updating the server (within a major version) but not the apps that aren't shipped with the server package
• update an individual app (not bundled with the server)

---

Or in other word admins shouldn't need a a mechanism to block updating for some apps since they should be the only ones having the permissions on the system to do it anyways (!).

[solracsf]

Main problems I'm trying to solve here are:

1. Multi-admins on a system : if for some reason an app must not be updated, it can be "pinned" (just like apt pin system) so one of the admins couldn't update that app without it being removed from the array.
2. Server updates also (auto) updates apps : when performing a server update, apps are updated, be it a minor or major upgrade, if a newer version is found on the app store. There is absolutely no control here.

There shouldn't be a reason not to update an app

Sometimes, there is a good reason.

[solracsf]

Once again here: nextcloud/groupfolders#4003

[provokateurin]

Btw we already have support for multiple app directories and having them marked read-only, however a lot of the logic around it is really broken and would be fixed by #51667

[MichaIng]

One question remains; if, while upgrading server to a major version (32>33) apps need update for compatibility reasons, how to handle this case effectively:

1. Deny server upgrade and ask administrator to empty the array?
2. Bypass that switch and upgrade apps nevertheless?

3. Show the app as incompatible with the target Nextcloud version and disable it automatically on update, like those apps which have no compatible version available yet. A disabled app is probably not better than an app on a version you didn't want it to have for whatever reason. But an inaccessible Nextcloud UI or whole instance due to an incompatible enabled app is worse.

2. Server updates also (auto) updates apps : when performing a server update, apps are updated, be it a minor or major upgrade, if a newer version is found on the app store. There is absolutely no control here.

Another idea is to generally not update apps with Nextcloud, unless required for compatibility. But means more efforts for admins to update everything.