Skip to content
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

trust private non-experimental apps #1527

Closed
wants to merge 1 commit into from

Conversation

andreas-p
Copy link

Referencing #561

Using the key 'trusted', an apps directory configured using apps_paths in config.php can be marked as non-experimental and trusted, despite not being listed in apps repositories.
All apps in the marked directory get an $app['level'] of 50, which is displayed as "private trusted" in the apps app, and won't get disabled when upgrading.

@MorrisJobke
Copy link
Member

MorrisJobke commented Sep 26, 2016

Mmmh ... yet another config switch ... I guess the proper way of doing this is to try to enable apps after the upgrade. On the other side it would be nice to not have the red label in the apps management.

@LukasReschke
Copy link
Member

LukasReschke commented Sep 26, 2016

Not a fan of this, the new app store with 11 will anyways kinda drop this notation since all apps are signed by default. (basically there's then a "normal" and an "official" app, local apps would simply count as normal then)

👎 from me on this one thus.

@andreas-p
Copy link
Author

On a production system, you won't like your apps being disabled. You might lose the group specific enabling, and scanning all disabled apps that might need reenabling is a PITA.
This flag basically declares the directory as local repository, making apps behave just like official apps.

@MorrisJobke
Copy link
Member

This flag basically declares the directory as local repository, making apps behave just like official apps.

Then this is bypassing a safety check. We try to enhance the updater for 11 anyways to not leave all non-official apps disabled, but rather try to enable them afterwards.

@andreas-p
Copy link
Author

@LukasReschke , how do you propose to deal with #561 ?

@LukasReschke
Copy link
Member

@LukasReschke , how do you propose to deal with #561 ?

Basically what @MorrisJobke said in #1527 (comment), we should improve the updater instead of adding code that will barely be used and tested.

@andreas-p
Copy link
Author

So you'd like experimental apps re-enabled as well?
What about marking apps non-experimental?

@LukasReschke
Copy link
Member

What about marking apps non-experimental?

In Nextcloud 11 local apps won't be marked as experimental or anything. They won't have any label at all.

@andreas-p
Copy link
Author

If re-enabling apps after upgrading (this includes appstore apps as well) respects previous enabling for specific groups that would be ok.

@MorrisJobke
Copy link
Member

If re-enabling apps after upgrading (this includes appstore apps as well) respects previous enabling for specific groups that would be ok.

Of course. The app should be in the same state as before.

@nickvergessen
Copy link
Member

Yeah let's do that. Sounds much more sane.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants