[Feature Request] Show owner/creator of task if you are not the owner/creator (for shared lists)

[gitaarik]

Steps to reproduce

1. Create 2 Nextcloud users
2. With user 1, create a task list
3. Share it with user 2
4. Create a task in this list
5. With user 2, open the task

Expected behaviour

With user 2, when you view the task created by user 1, in the details you see that it has been created by user 1.

Actual behaviour

I don't see which user created the task

Server configuration detail

Operating system: Linux 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64

Webserver: nginx/1.14.0 (fpm-fcgi)

Database: mysql 5.7.30

PHP version:

7.2.24-0ubuntu0.18.04.6
Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, sodium, session, standard, cgi-fcgi, apcu, mysqlnd, PDO, xml, apc, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, iconv, imagick, intl, json, exif, mysqli, pdo_mysql, Phar, posix, readline, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xmlreader, xmlwriter, xsl, zip, Zend OPcache

Nextcloud version: 18.0.6 - 18.0.6.0

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: unknown

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.4.0
 - activity: 2.11.0
 - apporder: 0.10.0
 - bruteforcesettings: 1.6.0
 - calendar: 2.0.3
 - cloud_federation_api: 1.1.0
 - comments: 1.8.0
 - contacts: 3.3.0
 - dav: 1.14.0
 - federatedfilesharing: 1.8.0
 - federation: 1.8.0
 - files: 1.13.1
 - files_pdfviewer: 1.7.0
 - files_rightclick: 0.15.2
 - files_sharing: 1.10.1
 - files_trashbin: 1.8.0
 - files_versions: 1.11.0
 - files_videoplayer: 1.7.0
 - firstrunwizard: 2.7.0
 - issuetemplate: 0.6.0
 - logreader: 2.3.0
 - lookup_server_connector: 1.6.0
 - mail: 1.4.1
 - maps: 0.1.6
 - nextcloud_announcements: 1.7.0
 - notes: 3.6.0
 - notifications: 2.6.0
 - oauth2: 1.6.0
 - onlyoffice: 4.3.0
 - password_policy: 1.8.0
 - phonetrack: 0.6.4
 - photos: 1.0.0
 - privacy: 1.2.0
 - provisioning_api: 1.8.0
 - recommendations: 0.6.0
 - serverinfo: 1.8.0
 - settings: 1.0.0
 - sharebymail: 1.8.0
 - spreed: 8.0.9
 - support: 1.1.1
 - survey_client: 1.6.0
 - systemtags: 1.8.0
 - tasks: 0.13.2
 - text: 2.0.0
 - theming: 1.9.0
 - twofactor_backupcodes: 1.7.0
 - updatenotification: 1.8.0
 - viewer: 1.2.0
 - workflowengine: 2.0.0
Disabled:
 - admin_audit
 - encryption
 - files_external
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "cloud.vedantawiki.org"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "18.0.6.0",
    "overwrite.cli.url": "https:\/\/cloud.vedantawiki.org",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "memcache.local": "\\OC\\Memcache\\APCu",
    "maintenance": false,
    "theme": "",
    "loglevel": 2,
    "updater.secret": "***REMOVED SENSITIVE VALUE***"
}

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption:

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Operating system: Ubuntu 18.04

[raimund-schluessler]

As far as I know, this information is not available from the Nextcloud DAV server. So this would be a server issue in the first place. @georgehrke Is this correct? Would it be possible to implement this?

[georgehrke]

This is not being exposed right now. What we should do is expose the actual database id of a calendar / calendar-object and then the calendar app / tasks app can fetch this information from the activity feed.

[raimund-schluessler]

This would result in a request per calendar / calendar-object. Wouldn't this create quite some load? Couldn't we also do that on the server side?

[georgehrke]

The problem is that we don't even store that information ourselves in dav. It's only available when the activity app is enabled.
Could you open a ticket in the server so we can elaborate our options there? Thx!

[gitaarik]

I don't know much about WebDAV, but could the owner element not be used for this?

http://webdav.org/specs/rfc4918.html#ELEMENT_owner