feat(settings): add admin & user setting iframe

[codewithvk]

• Resolves: #
• Target version: main

Summary

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Documentation (manuals or wiki) has been updated or is not required

[juliusknorr]

Some early feedback, general approach seems good 👍

[juliusknorr]

Ideally this would be an URL that can be obtained from the discovery endpoint of Collabora, could be a separate app element for settings

[codewithvk]

Added to my TODO, will fix it before merging PR.

[codewithvk]

Related serverside PR : nextcloud/server#50145

[pedropintosilva]

@codewithvk @juliusknorr thanks. Probably worth to create a separated PR for the vue conversion, right?

[elzody]

In order to resolve the failing tests, you should do the following:

1. Make sure all the new files (and existing files, even) have the SPDX reuse header at the top
2. Run composer run cs:fix to address formatting and styling issues, etc.
3. Run composer run psalm -- --no-cache which will inform you of errors which should be fixed

[codewithvk]

In order to resolve the failing tests, you should do the following:

1. Make sure all the new files (and existing files, even) have the SPDX reuse header at the top
2. Run composer run cs:fix to address formatting and styling issues, etc.
3. Run composer run psalm -- --no-cache which will inform you of errors which should be fixed

@elzody We could have one psalm error because we need to merge PR :nextcloud/server#50145 before.. I fixed other errors...Also could you please run CI - as I don't have access to run CI.

[juliusknorr]

We should call this differently as we want to remove the duplicate word "settings" from all seections we have (ref #4351)

[pedropintosilva]

How it looks now:

I have discussed with Vivek that we should also remove Collabora since it's part of Office settings section.

If we also remove settings (even thought I do see "Personal settings" in the #4351 you have referenced) then we either replace it with something such as "preferences" or - and I think better - we simply remove that h2 completely and let the headings in the iframe being h2 (so, autotext and workbook will become upper level which probably makes more sense)

[codewithvk]

@pedropintosilva Thanks for adding a screenshot :)

[juliusknorr]

@codewithvk Can you also add some screenshots of how this looks in the settings page for review of @marcoambrosini as designer?

[codewithvk]

@juliusknorr @elzody I'm not able to figure out why wopi integration for db test broken, any idea?

[codewithvk]

Modified bit of UI of iframe

cc: @marcoambrosini @juliusknorr @pedropintosilva

[pedropintosilva]

Modified bit of UI of iframe

cc: @marcoambrosini @juliusknorr @pedropintosilva

Awesome, much better, thanks!

I think We can still make it more clear in terms of the elements and their relation. What I mean is that right now the "Upload AutoText/Wordbook" buttons seem that they are referring to the list of files (which is not the case, those files were already uploaded). Best to clarify the main action by renaming it to "Add new AutoText" / "Add new Wordbook" but that seems a bit too long (specially when considering translations) -> so, what about "New AutoText" and "New Wordbook". I have noticed that in https://nextcloud-vue-components.netlify.app/#/Components/App%20containers/NcAppNavigation?id=ncappnavigationnewitem that sometimes they use the additional plus icon as a prefix (Maybe we could use it? @jancborchardt , @marcoambrosini )

[juliusknorr]

Sorry I missed that the server change was also required, but we cannot get that in for 31 anymore due to API freeze.

However you can directly access it by injecting IRootFolder and then fetching the path directly from it

		$instanceId = $this->config->getSystemValue('instanceid', null);

		if ($instanceId === null) {

		}

		return $this->rootFolder->get('appdata_' . $instanceId . '/richdocuments/your-path');

[codewithvk]

@juliusknorr Is it safe to access the rootFolder from a security perspective?

May be for now we can do it as it seems we don't have other options.

[juliusknorr]

Yes, that is fine, the server API that you have would do similar calls

[codewithvk]

@juliusknorr I have added this commit - could you please checkout and restart CI ? 3e6964b

[codewithvk]

@juliusknorr As of now temporary I'm sending stamp as time but we need to pass here Category folders etag/stamp - May be we can create method inside settingsService but still we need fetch stamp from Folder/SimpleFolder or even Node. I try to test with Node etag it seems not updating is something updated in child.

[juliusknorr]

As a simple approach you could try the using getMTime which is probably enough, but I'm not entirely sure this propagates as well

If that doesn't we may need to manually update the etag whenever a file is added/updated/removed through richdocuments

The following code should work for that then:

$folder->getStorage()->getCache()->update($folder->getId(), [
	'etag' => uniqid(),
]);

[juliusknorr]

Just for future reference, the reason the etag is not propagating directly is because we skip it in https://github.com/nextcloud/server/blob/41c53648ad18e3a94b6ba18ad0e6c7c09a520bd9/lib/private/Files/Storage/Common.php#L346 as in other cases we do not make use of that for anything in appdata or we have a separate mountpoint like for collectives where we can apply our own storage wrapper nextcloud/collectives@b54e6be but that won't work for the case here.