fix: expose via dav capabilities whether calendar app is enabled

[Antreesy]

• Ref: Don't link to calendar, if calendar is not enabled/available spreed#15249

Summary

• Expose whether calendar app is enabled to be able to link to it
• Allows Talk Desktop client to pick it up

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)

[nickvergessen]

/backport to stable31

[skjnldsv]

I would honestly just create a dedicated list of enabled apps for the logged in user.
Seems more generic and everyone could benefit from it :)

[Antreesy]

I would honestly just create a dedicated list of enabled apps for the logged in user

Sounds like a good idea, but for web applications it should be enough to rely on _oc_appswebroots, I think? Otherwise it can be done selectively to not increase a load on each webpage request, (e.g. if you have 100+ apps enabled, and eventually it's not going to be used by any app)

I don't even need this in Talk web page (we have initial state there), it just a bypass for Talk Desktop client to get that data from server capabilities periodically

[skjnldsv]

Sounds like a good idea, but for web applications it should be enough to rely on _oc_appswebroots, I think?

I don't think so, apps webroots doesn't mean the user have rights to use that app? 🤔

[SystemKeeper]

I don't think so, apps webroots doesn't mean the user have rights to use that app? 🤔

From

server/lib/private/Template/JSConfigHelper.php

Lines 81 to 93 in 35930a4

	if ($this->currentUser === null) {
	$apps = $this->appManager->getEnabledApps();
	} else {
	$apps = $this->appManager->getEnabledAppsForUser($this->currentUser);
	}
	foreach ($appsas$app) {
	try {
	$apps_paths[$app] = $this->appManager->getAppWebPath($app);
	} catch (AppPathNotFoundException$e) {
	$apps_paths[$app] = false;
	}
	}

I would assume it does? 🤔 Since it checks

server/lib/private/App/AppManager.php

Lines 207 to 213 in 35930a4

	publicfunctiongetEnabledAppsForUser(IUser$user) {
	$apps = $this->getEnabledAppsValues();
	$appsForUser = array_filter($apps, function ($enabled) use ($user) {
	return$this->checkAppForUser($enabled, $user);
	});
	returnarray_keys($appsForUser);
	}

?

But a general list would be nice, yea, we have dedicated capabilities in a few apps for that right now.

[susnux]

IMHO this does not belong to dav.
Instead put this is the calendar app, its already a mess that we cross link from app to other app.

You can then check if calendar capability is available or not.

[nickvergessen]

You can then check if calendar capability is available or not.

Makes also sense there, but it doesn't have any yet.

[ChristophWurst]

Is the capabilities endpoint always specific to a user or is it supposed to be global for the instance? I also see enable app for group as a special case that could be tricky to handle if we mix this up. Otherwise capability or general list of apps for the current user sounds good 👍

[Antreesy]

Made an attempt to move it to core capabilities, output is a list of enabled apps. I wonder if there is an issue in exposing this list?

• As 'guests' app account, I see the same list of apps - although some should be blocked?
• As public link visitor, I have no account - I see all the apps on the instance?
• as federated user - depends on how a proxying requests handles it (didn't test)?

[susnux]

output is a list of enabled apps. I wonder if there is an issue in exposing this list?

If it is the same as on the JS config, then no. In general I think everything in the JS config should be probably a capability to allow using this also in other locations than the webUI (e.g. see Talk desktop or clients etc).

[susnux]

BTW we now also have a OCS api for this in 32 and 31: #53569

[nickvergessen]

BTW we now also have a OCS api for this in 32 and 31: #53569

Not sure this is sufficient from our side, as it would add another API request when people load the talk dashboard?

[susnux]

Not sure this is sufficient from our side, as it would add another API request when people load the talk dashboard?

Well on webui there is the js config (also as initalstate) and clients need to fetch it anyways.

But I still think everything or at least most what is provided as js config should be a capability.

[Antreesy]

Superseded by nextcloud/calendar#8009