Vm: Rich workspaces

[szaimen]

I have tried the Nextcloud 18 release a bit and I really don't like the rich workspaces, because I think they are really confusing for most people and can spam your file structure with readme files.
So I would like to provde an option during the startup script to disable them, based on the command:
occ_command config:app:set text workspace_available --value=0
this will only work starting at 18.0.1: https://github.com/nextcloud/text/issues/586#issuecomment-578387536

[szaimen]

Since this would be already the 3rd additional configuration option, maybe we should think about extracting this into an additional whiptail for nextcloud configuration? (now we had 6 options in this one whiptail, 3 are server based things, and the 3 added by me are nextcloud configurations. We could do it like the additional_apps script is now solved?

[szaimen]

I will do a PR later on so that we can discuss it.

[enoch85]

I'm with you 100%, I feel exactly the same way.

Question is, should we make it default, or an option?

[szaimen]

Honestly: I would disable it by default but this is the Nextcloud VM and as you said before: it should be the Nextcloud that the developer team says that it should be so I would just add the option to disable it.

[enoch85]

OK, let's put it in "Extra configuration" as an option, like "Disable top notes in GUI".

[szaimen]

Since this would be already the 3rd additional configuration option, maybe we should think about extracting this into an additional whiptail for nextcloud configuration? (now we had 6 options in this one whiptail, 3 are server based things, and the 3 added by me are nextcloud configurations. We could do it like the additional_apps script is now solved?

What do you think about that idea?

[enoch85]

What do you think about that idea?

Nope, add it in existing whiptail. I don't want to clutter the setup with a lot of different whiptails.

Apps is one thing, Extra configuration is everything else.

[szaimen]

I have just created a PR for that :/

[szaimen]

I think it makes sense because this shouldn't be only bound to the initial setup, like the server configuration. And I really do think, that this is not the same like additional server configuration: it is nextcloud-configuration.
So it should have its own whiptail imo...
and because it is no server configuration, I think that you should also be able to change it later on...
I also think, that it is much better to maintain this way...

[szaimen]

Another example why putting all nextclojd configuration options into the startup script is probably not the best way:
If we decide to moce the cookielifetime script later on to another place or rename it, the startup script would fail. But if we just have the curl script linked here, we can change whatever we want later on without having to edit the startup script...