Do not cache the settings/sections in the database anymore

This caused more troubles then it had benefits, especially
when an app got disabled or was removed without being disabled.

Signed-off-by: Joas Schilling <coding@schilljs.com>

1 files changed, 12 insertions, 40 deletions

diff --git a/lib/public/Settings/IManager.php b/lib/public/Settings/IManager.php
index 1a1a4b8e661..52f12c3a8fb 100644
--- a/lib/public/Settings/IManager.php
+++ b/lib/public/Settings/IManager.php
@@ -49,46 +49,18 @@ interface IManager {
 	const KEY_PERSONAL_SECTION  = 'personal-section';
 
 	/**
-	 * sets up settings according to data specified by an apps info.xml, within
-	 * the <settings> element.
-	 *
-	 * @param array $settings an associative array, allowed keys are as specified
-	 *                        by the KEY_ constant of  this interface. The value
-	 *                        must always be a class name, implement either
-	 *                        IAdmin or ISection. I.e. only one section and admin
-	 *                        setting can be configured per app.
-	 * @since 9.1.0
+	 * @param string $type 'admin' or 'personal'
+	 * @param string $section Class must implement OCP\Settings\ISection
+	 * @since 14.0.0
 	 */
-	public function setupSettings(array $settings);
+	public function registerSection(string $type, string $section);
 
 	/**
-	 * attempts to remove an apps section and/or settings entry. A listener is
-	 * added centrally making sure that this method is called ones an app was
-	 * disabled.
-	 *
-	 * What this does not help with is when applications change their settings
-	 * or section classes during their life time. New entries will be added,
-	 * but inactive ones will still reside in the database.
-	 *
-	 * @param string $appId
-	 * @since 9.1.0
-	 */
-	public function onAppDisabled($appId);
-
-	/**
-	 * The method should check all registered classes whether they are still
-	 * instantiable and remove them, if not. This method is called by a
-	 * background job once, after one or more apps were updated.
-	 *
-	 * An app`s info.xml can change during an update and make it unknown whether
-	 * a registered class name was changed or not. An old one would just stay
-	 * registered. Another case is if an admin takes a radical approach and
-	 * simply removes an app from the app folder. These unregular checks will
-	 * take care of such situations.
-	 *
-	 * @since 9.1.0
+	 * @param string $type 'admin' or 'personal'
+	 * @param string $setting Class must implement OCP\Settings\ISetting
+	 * @since 14.0.0
 	 */
-	public function checkForOrphanedClassNames();
+	public function registerSetting(string $type, string $setting);
 
 	/**
 	 * returns a list of the admin sections
@@ -96,7 +68,7 @@ interface IManager {
 	 * @return array array of ISection[] where key is the priority
 	 * @since 9.1.0
 	 */
-	public function getAdminSections();
+	public function getAdminSections(): array;
 
 	/**
 	 * returns a list of the personal sections
@@ -104,7 +76,7 @@ interface IManager {
 	 * @return array array of ISection[] where key is the priority
 	 * @since 13.0.0
 	 */
-	public function getPersonalSections();
+	public function getPersonalSections(): array;
 
 	/**
 	 * returns a list of the admin settings
@@ -113,7 +85,7 @@ interface IManager {
 	 * @return array array of IAdmin[] where key is the priority
 	 * @since 9.1.0
 	 */
-	public function getAdminSettings($section);
+	public function getAdminSettings($section): array;
 
 	/**
 	 * returns a list of the personal  settings
@@ -122,5 +94,5 @@ interface IManager {
 	 * @return array array of IPersonal[] where key is the priority
 	 * @since 13.0.0
 	 */
-	public function getPersonalSettings($section);
+	public function getPersonalSettings($section): array;
 }