When the course name is really long, the folder and, therefore, the whole share cannot be created.
To do:

• research the exact length
• find a strategy for dealing with Problems possible:
  • throw warning for the course creator (downside - course must be renamed)
  • change all occurrences of creating and finding shares to use the shortened course name

[original reporter: @tobiasreischmann]

• The cloud in icon.svg could be larger within the folder, in order to improve its visibility.
• Other pictures are only relevant for README.md and should therefore be removed from pix/

[original reporter: @Dagefoerde]

[original reporter: @Dagefoerde]

Currently the group folders, which are displayed to a teacher are named like the groupid. However this is not helpful for the teacher since he only knows the group names.

[original reporter: @tobiasreischmann]

[original reporter: @tobiasreischmann]

... i.e. an admin can only guess which ownCloud user will own all folders.

[original reporter: @Dagefoerde]

Moodle's privacy API enables plugins to report metadata about stored personal data, and provides facilities for export and deletion of data. We need to implement that.

Note that we do not need to implement export/deletion for files that are not stored in Moodle; i.e. we do not need to work on files in an ownCloud instance. Nevertheless, we need to declare what we store in Moodle, and what personal data we transmit to an ownCloud instance.

The task does lots of work even if no technical user is logged in. It is only when it tries to create the first folder in a loop that it realises that it does not even have the rights.

Is there a way to obtain some status page / api from ownCloud, that can be used to check whether someone is logged in AND actually still has access?

[original reporter: @Dagefoerde]

If you create a collaborative folder with teacher-access and group-mode, students which are in no group at all can create a share for the teachers' root folder.
Additionally, we have to think about what should happen if:

• Students are in multiple groups? (resolved)
• Students change their group after the share is established?
• What permissions do students have that are not in any group? (Expected: none. Actual: ??)
• What should happen for groups that are created after the activity has been created? (see comment by @davosmith below)

[original reporter: @tobiasreischmann]

..even though the checkbox at the beginning of the activity configuration is turned off.
This is probably useful in course-wide folders, but should at least be made explicit.

[original reporter: @Dagefoerde]

I once created and deleted a single instance. Afterwards, the admin's activities overview page showed mod_collaborativefolders with 1 instance, although there should be none. It is possible that collaborativefolders_delete_instance is broken.

I am actually unsure whether

    if (!$collaborativefolders = $DB->get_record('collaborativefolders', array('id' => $id))) {

not sure whether ! negates the full thing or only the assigned variable!

[original reporter: @Dagefoerde]

[original reporter: @tobiasreischmann]

Hello,

when I connect with a moodle user (using oauth) and when I use collaborative folder; I have the following error message:
error/Could not upgrade oauth token

Admins should not be able to create a share to a folder if they are not enrolled as a teacher or student!!!

[original reporter: @tobiasreischmann]

The selectors in the styles.css should ideally contain the component name, e.g.

.path-mod-collaborativefolders .groupfolderinfo.details.generaltable th {
    // ...
}

Ref: https://docs.moodle.org/dev/Plugin_contribution_checklist#CSS_styles

The name of the capability "isteacher" is not fortunate, and as a consequence it then requires a lot of additional comments and explanations in both code and the UI.

What about if it was called something like mod/collaborativefolders:restrictedaccess.

Also, I don't fully understand why it needed to be implemented in this "negative" way:

Note: This is a restriction, not a capability. Don't use for deciding what someone MAY do, consider as MAY NOT instead.

Although such capabilities exists in core too, they should still be used rarely as exceptions really. Would not it be cleaner if

• mod/collaborativefolders:view was given to everyone as it is now (because it has an inbuilt behaviour used by the core) but it would represent the minimal /restricted level of access to the activity
• there was another, something like "edit" or "manage" or so which would give the user the full access to the folder - and this one would be then granted to students only.

This existing negative logic makes things only confusing. What if someone sets the "mod/collaborativefolders:isteacher" as prohibited etc. - all such multiple negations make things unnecessary complicated imho.

However, I can see how whole this concept of "being a teacher" (which was abandoned around Moodle 1.7 times) is hard-coded in the module's internal APIs so I don't expect this would be actually addressed.

Immediately after a user authorises Moodle to use ownCloud in his/her name (using the "Log in" button), Moodle should fetch the ownCloud username and store it in the user's session via MUC.

Motivation:

• The username is required to actually create shares by the system account (in order to know who to share it with). Right now, this results in an extra roundtrip for every share, because the plugin first asks for the username, an then creates the share. We can save this roundtrip.
• In addition, the username can be displayed right next to the "log out" button, thus reassuring users that the plugin is operating in the correct account.

In the German language pack it says "Öffnen in {a}" instead of "Öffnen in {$a}".

Hello,

when I connect with the moodle administrator (not using oauth) and when I use collaborative folder; I have the following error message:
The system account is unable to connect to NextCloud, so folders for this activity will not be created. Please inform the administrator about this.

Moodle 3.8.1+ (Build: 20200124)
Nextcloud 18.0.1

Log moodle apache:
[Thu Feb 27 15:51:41.725329 2020] [proxy_fcgi:error] [pid 1107:tid 139974150137600] [client ] AH01071: Got error 'PHP message: [client ] https://domaine Invalid Login Token: user Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36\n', referer: https://domaine/

After creating/removing a share, the plugin redirects to the view.php using a specific anchor, in order to scroll to the folder that the plugin operated on (e.g. view.php?id=100#folder-1).

Similar to forum posts, we can use the anchor to highlight the folder in order to visually distinguish it from the other folders.

Then the adhoc task to create the oc folders could be replaced by a scheduled task

[original reporter: @tobiasreischmann]

Currently the view.php has three optional params (reset, generate, logout). Since those actions are never used at the same time better use one PARAM_TEXT param, which holds the name of the action.

[original reporter: @tobiasreischmann]

Hallo!
Wenn ich einen Collaborativfolder einrichten möchte erhalte ich die folgenden Fehlermeldung:

Unable to share the folder with you: WebDAV error code 403

Habt ihr eine Lösung dafür?

Viele Grüße
Friedhelm

When opening the collaborative folder, the user should directly be asked to login to owncloud. Afterwards he is prompted once with question of a foldername. Then the share is directly triggered without further user interaction.

[original reporter: @tobiasreischmann]

Maybe, somehow, their owncloud account is lost or they legitimately possess more than one owncloud account.
mod_collaborativefolders assumes that once a folder is shared with a user, that user will always retain access to that share. This is not correct in the above scenarios.

There currently is no way to re-share a collaborative folder.

Found this issue while thinking about #1 (comment).

[original reporter: @Dagefoerde]

Task creates folders for an activity that does not even exist anymore.

Possibly related to #16

[original reporter: @Dagefoerde]

i.e. they don't realise that (currently) no folders will be created and that they have to nudge their admins.

[original reporter: @Dagefoerde]

... thus removing another level of indirection

[original reporter: @Dagefoerde]

for example, in addition to a link to owncloud, an iframe with owncloud could be included

[original reporter: @Dagefoerde]

The new API provides exactly what we need, including support for a technical user. Using it will help reduce continued development efforts on our side and makes it consistent with other Moodle Plugins.
Will resolve

• #14
• #15
• #23
  ... as we hand off responsibility to the core API.

Also, this will remove

• technicallogout.php
• \event\technical_user_loggedout

We have some explicit references to ownCloud, e.g., in language strings that are presented to the user. This is problematic for two reasons:
a) This works well with any service that relies on a combination of OCS and WebDAV (I just successfully tested with Nextcloud 15 RC 1).
b) Private clouds might not be called "ownCloud" (in our place, sciebo).

• 1. Turn the activity icon into something more neutral
• 2. Remove explicit references to names from the UI or make the display name configurable

ad 2.: We could take the name from the issuer. But, for instance in the repository configuration, the issuer name is never displayed to users, so admins might expect it to be private. Instead, maybe provide a setting.

We could place a special file in the root of the technical user's owncloud file system, e.g. .moodle-mod_collaborativefolders. The content could create some hash. That hash could be checked on re-login and, if it differs, a notification could be shown to the administrator, hinting at a possible (!) error.

Also, should we provide options to handle this, e.g. lock all existing instances on demand? This would be useful and necessary if the account actually changed for legit reasons.

[original reporter: @Dagefoerde]

The plugin uses the technical user ("System account") in order to manage folders. However, right now it assumes it works alone, and creates folders per instance in the root directory of the technical user. This may lead to problems if other plugins want to use the same account and might use the same folder structure.

Expected:
At the root level, the plugin should define a specific folder structure that is unique to this plugin (or, at least, very speaking), so that it does not conflict with other plugins. Folders per instance will be created below this folder structure, instead of at root level.

Moodle has made some assumptions about external services that were valid for Facebook, Google, and Microsoft, but that do not apply to ownCloud/Nextcloud. These issues must be resolved before it is safe (or even possible) to deploy mod_collaborativefolders.

• https://tracker.moodle.org/browse/MDL-59511 Can't connect a system account to OAuth 2 services that do not provide email in userinfo
• https://tracker.moodle.org/browse/MDL-59512 Can't connect a system account to OAuth 2 services that only support client authentication via Basic Auth
• https://tracker.moodle.org/browse/MDL-59746 OAuth 2: upgrade_token does not urlencode parameters
• https://tracker.moodle.org/browse/MDL-59844 Enable OAuth 2 token-based authentication for requests in webdav_client
• https://tracker.moodle.org/browse/MDL-59869 If authorisation for an OAuth 2 system account expires, notifications are not sent
• https://tracker.moodle.org/browse/MDL-59889 Can't refresh authorisations of OAuth 2 system accounts at services that do not provide email in userinfo

This list might grow and issues may be resolved. We try to keep it up to date with current Moodle progress. Any help in these tickets is much appreciated!

If changing the folder name via owncloud, there are much more possibilities!

[original reporter: @tobiasreischmann]

Currently, settings.php does weird stuff with parameters. However, it may be included in arbitrary places. I am also not sure if any capabilities are evaluated at all. This file must be carefully refactored to ensure that no weird side effects can happen while an administrator is not explicitly changing settings of mod_collaborativefolders

[original reporter: @Dagefoerde]

It would be useful to be able to define the default for whether teachers are able to view the created folders.