Hi,

With sharing.federation.show_remote_shares_as_internal = true, is it possible to add such a share by entering the user's name in the internal shares section? I currently don't have a GS setup to validate this myself.

Given that federation and GS are quite complex topics with various configuration options that can influence behavior, I think we should do another round of planning to adjust the new sharing sidebar to meet expectations. I'm concerned that a simple flag to move shares from one list to another might not be sufficient.

With sharing.federation.show_remote_shares_as_internal = true, is it possible to add such a share by entering the user's name in the internal shares section? I currently don't have a GS setup to validate this myself.

Yes, that is the goal (or how it has been before the latest change). For a GS setup with this config flag (and it ultimately will do more than just this PR). In the end federated shared (in a GS setup/scenario) shall behave (from a user perspective) like local shares (while this will have its limitations or in other word won't be possible 100% given technical limitations).

So another (the second aspect to come later) is to hide the (remote) info on the username on the share-item in the sidebar because "should behave local".

@kesselb This PR is mandatory for the next release (!).

Iirc we treat federation different with global scale anyways so we could just check if global scale is enabled and if it is then we just treat any remote user as internal at least for the sharing sidebar maybe this could be an option so we don't need any UI option.¹

Currently, the administrator has to set the configuration value to revert to the old behavior.

I assume Ferdinand was referring to the following code. With GS enabled, the sharees API will query the lookup server regardless of the given share type, and therefore also return users from other nodes in the GS compound.

While I don't fully understand how onlyInternalFederation (gs.federation true/false) influences this, we could use isGlobalScaleEnabled as the default value to revert to the old behavior for affected customers without requiring any additional actions on their end. However, we should keep the option to override it for those who might need it.

Example:

$this->initialState->provideInitialState(
	'showFederatedSharesAsInternal',
	$this->appConfig->getAppValueBool('show_federated_shares_as_internal', $this->globalScaleConfig->isGlobalScaleEnabled())
);

/compile

/compile

II would move ConfigLexicon.php to lib/ to keep consistency with other apps (as /lib/AppInfo/ was not accepted ;p)

/compile

@nfebe is the setting documented elsewhere than here ?

@nfebe is the setting documented elsewhere than here ?
nextcloud/documentation#13316

Sorry, but that sounds a bit extreme to add a custom config for this, no?