Open uwe347 opened 6 years ago
@Julian1998 can you please have a look? THX
Please test this fix - very likely the same issue - https://github.com/owncloud/calendar/pull/839 THX
Sorry for being only a user with no programming skills... I don't find the place where to apply the fix.
This page shows the line which has to be changed in the file named "js/app/controllers/calendarlistcontroller.js", but I can't find any file with this name in my owncloud installation. ('find owncloud -name calendarlistcontroller.js' shows nothing). By searching for the string "scope.updateExistingUserShare = function" I discovered, that similar lines (as mentioned in the commit #839) can be found in the file apps/calendar/js/public/app.js line 617. So I changed this line to
$scope.updateExistingUserShare = function (calendar, userId, displayname, writable) {
but this doesn't help: The problem is still there.
So I think I need help how to apply this fix...
You Applied the patch correctly. Please reshare the calendar and it should work.
This doesn't work in my case, OC 9.1.7 and calender 1.5.4 with Patch #839
@DeepDiver1975: Sorry for answering that late. It still doesn't work. I am not shure, what you mean with "reshare the calendar", because the problem I described occures during the step of sharing. As I described, the checkmark-fields to allow modify and share do not appear after selecting one of the valid usernames from the list. There is only one checkmark-field for "share link" (which makes the calendar open for any user, not only for those with an account).
@uwe347 check #823 and there the post from @Ricardo665 . This works for me. But as soon as you try to share share a calendar and type in the user name into the search field the logfile comes up with
Error | OCP\Share | Sharing backend for principals not found
The strange thing with this bug is, that old shared calendars, which did exist before upgrading to 9.1.7, work without problems. New calendars can't be shared.
Using the latest stable 10.7, I too cannot share new calendars (while the old ones works correctly).
However I do not see any Sharing backend for <> not found
error in the owncloud.log
file, and when I type a user or group name in the share field, nothing happens, no selection is displayed at all.
This is annoying and it's happening for quite some time now (I though upgrading from 9 to 10 would solves this, it did not)!
Strange observations .... Can I See some Screenshots pleased. Maybe this helps to resolve the Situation
The screenshot:
You can see there that while I'm typing the start of a group name, no menu is shown, and that one of the older calendar is correctly shared.
Any error in the browser console?
Yes there are.
I see that on each keystroke a GET
request is sent to the server, and I then get the following error message:
TypeError: result.ocs.data.exact is undefined
I tried pasting the url from the GET
request in a separate tab and I get:
The url:
https://example.com/owncloud/ocs/v1.php/apps/files_sharing/api/v1/sharees?format=json&search=Sec&perPage=200&itemType=principals
The result:
{
"ocs": {
"meta": {
"status": "failure",
"statuscode": 999,
"message": "Invalid query, please check the syntax. API specifications are here: http:\/\/www.freedesktop.org\/wiki\/Specifications\/open-collaboration-services. DEBUG OUTPUT:\n"
},
"data": []
}
}
This is a great finding! THX
What are the exact versions of owncloud server (have a look at version.php) and the calendar app (apps/calendar/appinfo/info.xml)
THX
The version:
$OC_Version = array(10,0,7,2);
$OC_VersionString = '10.0.7';
$OC_Build = '2018-02-19T16:29:54+00:00 90535c97bad0d5455e92d1190012fb856cf7e8b0';
The calendar one:
<?xml version="1.0"?>
<info>
<id>calendar</id>
<name>Calendar</name>
<version>1.4.2</version>
<licence>AGPL</licence>
<author>Georg Ehrke, Raghu Nayyar, Bernhard Fröhler</author>
<dependencies>
<owncloud min-version="9.0" max-version="10.0" />
</dependencies>
<description>Calendar GUI for the server-integrated CalDAV server</description>
<documentation>
<user>http://doc.owncloud.org/server/9.0/user_manual/pim/calendar.html</user>
</documentation>
<category>productivity</category>
<screenshot>https://raw.githubusercontent.com/owncloud/screenshots/9d7c40b3f9694f4fabca464870524b9b962c8705/calendar/screenshot.png</screenshot>
<website>https://github.com/owncloud/calendar/</website>
<bugs>https://github.com/owncloud/calendar/issues</bugs>
<repository type="git">https://github.com/owncloud/calendar.git</repository>
<ocsid>168707</ocsid>
</info>
~
1.4.2
please upgrade - meanwhile there is 1.5.6 available
I just ran:
sudo -u www-data ./occ market:upgrade
and now the server is not responding.
If I run
sudo -u www-data ./occ market:list
I get the error message: No marketplace connection: Client error response [url] https://marketplace.owncloud.com/api/v0/api/v1/platform/10.0.7/apps.json [status code] 404 [reason phrase] Not Found
this url is wrong - please have a look at your config.php
there is a setting appstore.url of similar - just remove the whole line and run the upgrade command again
Ok I removed the buggy line from config.php
, ran sudo -u www-data ./occ market:list
and it listed all the available apps correctly.
Now, when I run sudo -u www-data ./occ market:upgrade
is see no output and it get back to the command prompt.
When I check again apps/calendar/appinfo/info.xml
, I see that it did not get updated and is still at the v1.4.2
. The permissions on the apps
directory are correct.
(Is there an owncloud chat somewhere (irc/gitter/discord/slack) we could use? This would I think be more suited than here)
I specified the names of the apps I wanted to upgrade, and it did the trick:
sudo -u www-data ./occ market:upgrade calendar
Now the website is running correctly again so far.
Shouldn't sudo -u www-data ./occ market:upgrade
upgrade all the installed app automatically?
With the latest calendar version 1.5.7
, I do not see the text field when clicking on the share
icon, only the checkbox to share with the public:
Shouldn't sudo -u www-data ./occ market:upgrade upgrade all the installed app automatically?
with the option --all it does.
With the latest calendar version 1.5.7, I do not see the text field when clicking on the share icon, only the checkbox to share with the public:
can you please check again for errors in the browser console? also try with a different language - e.g. English - just to rule out that a potential wrong translation is making trouble.
furthermore: are you trying to re-share an already with you shared calendar?
No errors are shown in the console when I click the 'share' icon, nor any network requests (which I checked are shown if I click the 'Share link' checkbox).
I will not try to re-share an already shared calendar, since it could just break the share permanently and I cannot afford that.
I've switched to 'English', and nothing more happens.
with the option --all it does.
Perhaps using no arguments are at all could either do the same thing as --all
, or display a 'usage message' because right now it does nothing.
I will not try to re-share an already shared calendar, since it could just break the share permanently and I cannot afford that.
Maybe I was not explicit enough. Sorry.
I can reproduce your behavior when I try to share a calendar which was previously shared with me. Looks like re-sharing is no supported. I need to have a closer look.
Perhaps using no arguments are at all could either do the same thing as --all, or display a 'usage message' because right now it does nothing.
Well, on my end calling that command does nothing and just returns:
# sudo -u www-data ./occ market:upgrade
#
But I guess that's another issue!
I can reproduce your behavior when I try to share a calendar which was previously shared with me. Looks like re-sharing is no supported. I need to have a closer look.
For info those calendars I cannot share are freshly created ones; I never shared them before.
Did you by accident disable sharing in the admin settings?
The share option is enabled. To be sure I toggled it few days ago, with no effect
Le April 18, 2018 6:52:44 AM UTC, "Thomas Müller" notifications@github.com a écrit :
Did you by accident disable sharing in the admin settings?
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/owncloud/calendar/issues/828#issuecomment-382281968
Still the same with owncloud 10.0.8.5 and calendar 1.5.7. I switched sharing option off and on again, as AlexandreBonneau did.
Here are two screenshots of what happens:
At first I type in the name of the user I want to share with. The user is found, so the name comes up after typing the first few characters:
After clicking on the user's name, the field disappears. My entry stays in the input box, but no sharing is done. RETURN key doesn't help.
In addition to my last comment: here are all details of my configuration concerning "sharing"
After clicking on the user's name, the field disappears. My entry stays in the input box, but no sharing is done. RETURN key doesn't help.
Any error in the browser console?
Yes:
05:19:39.338 Error: Sharing calendar failed 1 - app.min.js:3:25234
I need to see the network request which is failing
I am not sure where to gather the information you need, but I try to guess... using web-developer-functions of my firefox browser > network analysis ("Netzwerkanalyse" Ctrl+Shift+E) and copied some information from the moment, when i clicked on the username ("kristine"):
GET /owncloud/ocs/v1.php/apps/files_sharing/api/v1/sharees?format=json&search=kristin&perPage=200&itemType=principals HTTP/1.1
Host: MYHOSTNAME.de
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: de,en;q=0.7,en-US;q=0.3
Accept-Encoding: gzip, deflate, br
requesttoken: <DELETED>
OCS-APIREQUEST: true
X-Requested-With: XMLHttpRequest
Cookie: <DELETED>; oc_sessionPassphrase=<DELETED>
DNT: 1
Connection: keep-alive
HTTP/1.1 200 OK
Date: Thu, 03 May 2018 16:31:02 GMT
Server: Apache/2.4.18 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Security-Policy: default-src 'none';manifest-src 'self';script-src 'self' 'unsafe-eval';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src 'self';connect-src 'self';media-src 'self'
Content-Length: 308
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
{"ocs":{"meta":{"status":"ok","statuscode":100,"message":"OK","totalitems":"","itemsperpage":""},"data":{"exact":{"users":[],"groups":[],"remotes":[]},"users":[{"label":"kristine","value":{"shareType":0,"shareWith":"kristine","shareWithAdditionalInfo":"MAILNAME@MAILDOMAIN.de"}}],"groups":[],"remotes":[]}}}
--------------------------------------------------------------------------------
GET /owncloud/index.php/avatar/kristine/32 HTTP/1.1
Host: MYHOSTNAME.de
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: de,en;q=0.7,en-US;q=0.3
Accept-Encoding: gzip, deflate, br
requesttoken: <DELETED>
OCS-APIREQUEST: true
X-Requested-With: XMLHttpRequest
Cookie: <DELETED>; oc_sessionPassphrase=<DELETED>
DNT: 1
Connection: keep-alive
If-Modified-Since: Thu, 03 May 2018 16:28:45 +0000
HTTP/1.1 200 OK
Date: Thu, 03 May 2018 16:31:05 GMT
Server: Apache/2.4.18 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: public
Content-Security-Policy: default-src 'none';manifest-src 'self';script-src 'self' 'unsafe-eval';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src 'self';connect-src 'self';media-src 'self'
Last-Modified: Thu, 03 May 2018 16:31:05 +0000
Content-Length: 35
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
{"data":{"displayname":"kristine"}}
Uppercase letters show some points, where I deleted sensitive information as my hostname and some cookies, sessionPassphrase,... If those informations should be necessary for your research, let me know how I can send this information in a confidential manner.
P.S.: Let me know, if this is not what you need. In that case I need more advice how to gather the right information and how to do it with my firefox browser.
I'm guessing this is a slightly different bug that what I'm experiencing since you at least get to select a user/group name, which I do not even see.
For info, it's still impossible to share any calendar using the latest 10.0.9.5
.
This is a critical bug.
I'm not sure this is the same issue but when I attempt to delegate access to another user (using macOS 10.14.1 Calendar app) if fails with an error and the following console log entry:
[com.apple.calendar.store.log.delegates] [Getting granted delegates failed with error Error Domain=CoreDAVHTTPStatusErrorDomain Code=404 "(null)" UserInfo={CoreDAVHTTPHeaders=<CFBasicHash 0x7fc577ddb060 [0x7fffa75768f0]>{type = immutable dict, count = 19, entries => 0 : Content-Type = <CFString 0x7fc57ab92970 [0x7fffa75768f0]>{contents = "application/xml; charset=utf-8"} 1 : Keep-Alive = <CFString 0x7fc57f165b50 [0x7fffa75768f0]>{contents = "timeout=20"} 2 : Pragma = no-cache 3 : Content-Security-Policy = <CFString 0x7fc57f1315b0 [0x7fffa75768f0]>{contents = "default-src 'none';"} 5 : Set-Cookie = <CFString 0x7fc580072290 [0x7fffa75768f0]>{contents = "oc_sessionPassphrase=ZGsYZZOm%2BhlMzMgFi0hEV20GeWS68Urg0uei4Os04gVbZgoSzCZ%2FvApvIiUa648RG3ACW12fe6vXOtmUiask6v5%2B9%2FOPj3Dn9ISgPuWi8VIv%2F4u58DSCpG7VSYpUbR5v; path=/; secure; HttpOnly, oc73e1wr403r=knlt1ss0lojb0vi730dhqajmq2; path=/; secure; HttpOnly, cookie_test=test; expires=Thu, 29-Nov-2018 18:30:45 GMT; Max-Age=3600"} 6 : Server = nginx 7 : X-Download-Options = noopen 8 : X-XSS-Protection = <CFString 0x7fc57ab87d00 [0x7fffa75768f0]>{contents = "1; mode=block"} 9 : Expires = <CFString 0x7fc57f13e0c0 [0x7fffa75768f0]>{contents = "Thu, 19 Nov 1981 08:52:00 GMT"} 10 : X-Permitted-Cross-Domain-Policies = none 11 : Transfer-Encoding = <CFString 0x7fffa72f7590 [0x7fffa75768f0]>{contents = "Identity"} 12 : Cache-Control = <CFString 0x7fc57abbc8f0 [0x7fffa75768f0]>{contents = "no-store, no-cache, must-revalidate"} 13 : Date = <CFString 0x7fc57f15d760 [0x7fffa75768f0]>{contents = "Thu, 29 Nov 2018 17:30:45 GMT"} 14 : X-Robots-Tag = none 15 : Content-Encoding = gzip 17 : Connection = <CFString 0x7fffa7604cb8 [0x7fffa75768f0]>{contents = "keep-alive"} 19 : X-Content-Type-Options = nosniff 21 : X-Frame-Options = <CFString 0x7fc57abddae0 [0x7fffa75768f0]>{contents = "SAMEORIGIN"} 22 : Vary = <CFString 0x7fffa7608cf8 [0x7fffa75768f0]>{contents = "Accept-Encoding"} } } for account david (0103D403-673B-48E9-B940-C80219A41555)]
When I attempt to share a calendar (also using macOS 10.14.1 Calendar app) I get the following error reported by dialog box:
The request for account “OwnCloud Synology” failed.
The server responded with “501” to operation CalDAVUpdateShareesQueuableOperation.
I running ownCloud 10.0.10 on a Synology diskstation 916+ with DSM 6.2. Sharing is enabled in the ownCloud user settings page.
Sorry if this is a different issue than reported above.
Is there a solution in meantime? I have the same problem with sharing calendars to group or persons. It started the same time as listed above an now I have Owcloud 10.3.1 and Calendar App 1.6.3 but I still can't share calendars to other persons except public shares! Any help?
@FKBOX I haven't found one since 2017, however since sharing works with previous calendar, perhaps technically it could be possible to edit the database manually? This is very hacky, but since this critical bug does not seem to be active anymore, that might be your best bet.
I did a new install in vbox and I could share calenders. Then I restored my database and I coudn't share anymore. So it is a problem of Database structure, but there is no documentation how it has to be. So it is a long run of reverse engineering to compare an new database to the existing. I never get help from the community. So I stop posting problems.
Steps to reproduce
Expected behaviour
The checkmark-fields (those to allow modify and share) should appear after selecting one of the valid usernames from the list. I looked after the changes written in this commit: https://github.com/owncloud/core/commit/dcb92b84cf53d10b2d4be3109fad1a002be18225 All changes in those four files shown there are implemented (as part of 10.0.3.3 an calendar 1.5.4, I guess).
Actual behaviour
no reaction after selecting a valid username, no access to the shared calendar for the other user.
Server configuration
I'm using calendar app 1.5.4 on owncloud version 10.0.3.3 on ubuntu 16.04LTS with Apache/2.4.18, mysql, PHP version 7.0.22-0ubuntu0.16.04.1 owncloud is set up from 9.x via 9.1.5.2 to 10.0.0 to 10.0.3.3 (I don't know the exact version steps on that route any more)
Login as admin user into your cloud and access http://example.com/index.php/settings/integrity/failed paste the results here: No errors have been found.
List of activated apps: output of 'sudo -u www-data ./occ app:list' Enabled:
ownCloud configuration report from admin page: config_report_20171117.json.txt
Are you using external storage, if yes which one: local/smb/sftp/... no
Are you using encryption: yes/no no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... no
Client configuration
Browser: Firefox Quantum 57.0 (64-Bit) Operating system: xubuntu 16.04LTS
CalDAV-clients: android CalDAVsync by Marten Gaida