Unwanted Readme feature

[alankeny]

Steps to reproduce

1. Enable the Text app
2. Let users behave like users

Expected behaviour

Under no circumstances do I want a large clickable area at the top of every folder that creates an empty Readme.md file in any directory on my server. The Text app should have left this feature to the Readme app for those that wanted it, or it should have provided an option to disable this feature.

Actual behaviour

My organization doesn't use README files. Nobody that uses my server has any idea what they're for or even why they exist. As soon as any user clicks anywhere near the top of a folder listing, the Text app creates a Readme.md file in the current folder. Even when the user had no intention of writing anything, the app still creates an empty file. This is going to leave my server littered with empty Readme.md files. Even for those that want this feature, I would think an app would delay creating the file until the user enters some text. If all of the text is deleted, shouldn't the file be deleted too, so the app cleans up after itself?

In those rare instances when a user sees their mistake and tries to clean up the mess immediately, they will click on the three dots menu and select the "Delete file" option. This results in the error, "Network connection error: Could not connect to the document". No amount of clicking on the retry button gets the error to go away. The user has to reload the page to clear the error and verify that the unwanted file was actually deleted.

I don't understand why this feature is in the Text app. There was already an app called "Readme" for those that wanted it. As a temporary workaround, I have hidden this functionality with the following custom CSS:

#filelist-header #rich-workspace {
  display: none
}

Server configuration detail

Operating system: Linux 5.3.13-1-pve #1 SMP PVE 5.3.13-1 x86_64

Webserver: Apache (apache2handler)

Database: mysql 10.3.18

PHP version: 7.3.11-1~deb10u1

Nextcloud version: 18.0.0 RC2 - 18.0.0.9

[alankeny]

Thanks only to this post on the support forum, I found the setting I was looking for. While in the Files app, click on settings in the lower left corner, and uncheck the option Show rich workspaces.

The documentation probably needs to be updated. This new feature was enabled by default, but it isn't mentioned in the CHANGELOG.md. I never would have guessed that "rich workspaces" meant allowing users to create README.md files that are displayed at the top of folder listings.

My other feedback stands. The file shouldn't be created until the user enters some text, and it should be deleted if there's no text remaining in the file.

[fvdm]

On our instance the big white box is confusing the users; it is messing with the otherwise clean UI and simple experience. At the very least it should be possible to globally disable this feature without the CSS trick. Our users are not so tech savvy to look around for the hidden and confusingly named 'rich workspaces' setting.

Personally I find it odd that a file editor is (by default) messing with the main views.

[r2evans]

@alankeny have you seen the reference to workspace_enabled? I don't know how to disable a user-configuration like this (either per-user or globally). Any thoughts?

(The comment of // FIXME: save to app config isn't reassuring :-)

text/src/views/FilesSettings.vue

Lines 47 to 60 in d6d1bad

	// FIXME: save to app config
	if (this.showWorkspace) {
	emit('Text::showRichWorkspace')
	axios.post(generateUrl('/apps/text/settings'), {
	key: 'workspace_enabled',
	value: '1',
	})
	} else {
	emit('Text::hideRichWorkspace')
	axios.post(generateUrl('/apps/text/settings'), {
	key: 'workspace_enabled',
	value: '0',
	})
	}

text/lib/AppInfo/Application.php

Lines 80 to 88 in fc86a67

	$this->config->getAppValue(self::APP_NAME, 'workspace_available', '1') === '1'
	);
	$this->initialStateService->provideInitialState(
	self::APP_NAME,
	'workspace_enabled',
	$this->config->getUserValue($this->userSession->getUser()->getUID(), self::APP_NAME, 'workspace_enabled', '1') === '1'
	);
	});
	}

text/lib/Controller/SettingsController.php

Lines 39 to 47 in d6d1bad

	*/
	private $config;
	const ACCEPTED_KEYS = [
	'workspace_enabled'
	];
	public function __construct($appName, IRequest $request, IConfig $config, $userId) {
	parent::__construct($appName, $request);

text/src/files.js

Lines 31 to 39 in 2258923

	__webpack_nonce__ = btoa(OC.requestToken) // eslint-disable-line
	__webpack_public_path__ = OC.linkTo('text', 'js/') // eslint-disable-line
	const workspaceAvailable = loadState('text', 'workspace_available')
	const workspaceEnabled = loadState('text', 'workspace_enabled')
	registerFileCreate()
	document.addEventListener('DOMContentLoaded', () => {

[alankeny]

As far as I can tell the workspace_enabled user setting is where the "show rich workspaces" option from the web interface is stored. If this user setting is set to 1 either with the checkbox in the web interface or with the command line occ user:setting <username> text workspace_enabled 1, the rich workspace is shown in the main view for that user. If it's set to any other value, the rich workspace is hidden. If this user setting is deleted, the rich workspace is shown by default.

I tried to set a bunch of different values for the text app settings workspace_available and workspace_enabled to get the rich workspace to be disabled by default. None of them worked to hide the rich workspace, even after I deleted the user setting.

Here are a few examples of the commands I tried:

occ config:app:set text workspace_available --value=0
occ config:app:set text workspace_available --value=false
occ config:app:set text workspace_enabled --value=0
occ config:app:set text workspace_enabled --value=false

At this point I'll probably put most of my effort into getting the original markdown editor working again, so I can remove this app. I need an editor that doesn't modify and then break existing markdown so much, and I'd like a text editor that's good for editing code. Collaboration and "rich workspaces" just aren't a priority for me.

[r2evans]

Thanks, I hadn't (yet) tried occ user:setting ... text workspace_enabled 0, thank you. Perhaps the fact that that step was ineffective can be explained by the // FIXME: save to app config comment?

I actually like the premise of the "Workspace", though the "always on, cannot disable" aspect is truly troublesome. And the windows client's inability to deal gracefully, nextcloud/desktop#1755, is absolutely disabling for me. It would be better, in my opinion, if we could change the automatic filename used so that we could side-step the windows-case problem by not syncing it. In many environments, "readme.md" (whatever the case) is too common a filename to be globally excluding from client-sync.

[alankeny]

I can't tell from the code or that comment if the intention is to have an app level setting or not. I would want to ensure that an app level setting to disable rich workspaces would override any user level setting. If the administrator decides to disable the feature, users should not be able to override that decision.

I agree that the premise of workspaces is fine, if that's what you want. Unfortunately this feature has very little to do with editing text and markdown files, so it really should have stayed in a separate app for those that wanted this feature specifically.

[juliusknorr]

Not being able to disable the rich workspaces globally was actually a bug in 18.0.0 and will be fixed in 18.0.1 with #597

Once that is releeased you can disable the feature by running:

occ config:app:set text workspace_available --value=0

[My1]

is there a reason this is OCC only? not everyone (webhosting ftw) has acess to occ easily

[Baptistou]

is there a reason this is OCC only? not everyone (webhosting ftw) has acess to occ easily

You can install and use the app "OCC Web" :
How to use occ commands on a Shared Hosting without SSH access

[alankeny]

I tend to agree with @fvdm. It's really odd that this feature is installed with an editor. Should someone using a web host that wants to edit files, but doesn't want rich workspaces, be required to load the OCC Web app just so they can disable a feature that doesn't really have anything to do with editing files? It would have been much easier for everyone if Rich Workspaces had stayed in its own app.

[Subnet-Masked]

Like @alankeny, I completely agree with @fvdm and I also agree with @My1 .
This should really be a toggle in settings that allows us to disable this globally. It is very confusing for my users and takes up a lot of space, thus ruining a nice clean UI.

"It would have been much easier for everyone if Rich Workspaces had stayed in its own app."

I fully agree with this. I had tried that app in the past with the same result as stated above: Confused users.

Edit: Formatting error for quote

[ChrisB85]

I tried to run:

occ config:app:set text workspace_available --value=0

but all I get is:

Not enough arguments (missing: "app, name").
config:app:set [--output [OUTPUT]] [--value VALUE] [--update-only] [--] <app> <name>

So I tried also:

config:app:set --value=0 text workspace_available

and

config:app:set --value 0 text workspace_available

but the results are the same.
I'm using docker version of NC (18.0.3).

[kobuki]

Not being able to disable the rich workspaces globally was actually a bug in 18.0.0 and will be fixed in 18.0.1 with #597

Once that is releeased you can disable the feature by running:

occ config:app:set text workspace_available --value=0

This does work, but we lose the functionality of readme.md completely. Even if I intentionally add a readme.md to a directory, it's not displayed when the above setting is active. The readme.md functionality, as is, confusing and useless.

[chaosgrid]

@kobuki You can use the other Readme.md app for that thankfully: https://apps.nextcloud.com/apps/files_readmemd

I also do not understand why there is no global app setting in the admin settings for this? Why do I have to go into occ command line to disable rich workspaces globally?

[kobuki]

@chaosgrid: Yes, I've tried it. It's useless, as it puts the readme contents in the bottom, whereas with long lists of images or files, etc. on screen it needs to be on the top for users to see at first glance, without scrolling to the bottom to find out it's (not) there. It tries to mime the GitHub behavior but it doesn't fit the general use case in NC. I know, I can create a header file, but that, again is out of the normal use case the original built-in functionality is for with README.md (which is pretty neat, but has this bug).

[chaosgrid]

@kobuki

But you can simply set it up in the configuration of that app so that the header file is actually readme.md (check the app settings in the admin area).

[kobuki]

Thanks, I'll try that, but I think this issue will be fixed in the base sooner or later.

[pwnoobz]

It's a very unpleasant experience. It's odd that I have to occ it instead of ENABLE it. It's an unwanted feature. Please consider fixing this.

[r2evans]

@pwnoobz while I agree, I also recognize that this is a closed issue and the developers might not notice (or act on) the comment. Perhaps you should open a new issue as a "feature-request: default 'no' workspace"? It doesn't appear to be a current issue, including the "Workspace polishing" issue #452.

[kobuki]

Oh, it has been closed? So we will need to live with the fact that when the user clicks on the wrong place, the interface will be cluttered with a large empty space? If it has been fixed by some other issue or commit, someone in the know please mention it here.

[r2evans]

Yes, scroll up about half-way to the top and notice

Plus, at least in my display, I have a hanging-header:

I think they are tweaking some portions of it. And while I admit I have not been tracking all dev recently, I've not seen any work on either (1) defaulting to "no", or (2) an ability to disable it within user- or system-settings UI.

[kobuki]

I now know it's closed, I just didn't notice it earlier. But closing an issue doesn't always mean it has been solved.

[dacoex]

@kobuki
Thanks for coming in.
Please comment further on the still open issue:
https://github.com/nextcloud/server/issues/19938

[r2evans]

@kobuki , sorry, was not suggesting, I can see my last comment is framed poorly. Fully agree that closed != solved.