Shared calendars not editable via caldav #26667

romris · 2016-11-21T09:54:29Z

Steps to reproduce

Open (via caldav) a calendar that is shared with you and for that you have the permission to make changes
Try to make changes
Synchnonize and see that your changes have no effect

Expected behaviour

Changes should be synchronized.

Actual behaviour

Changes are not synchronized.

Server configuration

Operating system: Ubuntu

Web server: Apache

Database: MySQL

PHP version:

ownCloud version: 9.1.2

PVince81 · 2016-11-22T14:03:48Z

@DeepDiver1975 is this a known issue ?

cgogolin · 2016-11-24T13:40:44Z

I think I have the same issue. It started with the update 9.1.1-1.2 -> 9.1.2-1.1.

Since then I can no longer edit or add entries in/to shared calendars via carddav. This happens even though the user has granted me permission to edit and the "can edit" box is also ticked in the owncloud calendar app. I can still create and add entries via the owncloud web interface. I can however no longer edit shared calendars with davdroid and evolution mail.

Davdroid says:

<?xml version="1.0" encoding="utf-8"?>[LF]
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">[LF]
  <s:sabredav-version>3.0.9</s:sabredav-version>[LF]
  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>[LF]
  <s:message>Principal with name users not found</s:message>[LF]
</d:error>[LF]

EXCEPTION:
at.bitfire.dav4android.exception.NotFoundException: 404 Not Found
        at at.bitfire.dav4android.DavResource.checkStatus(DavResource.java:310)
        at at.bitfire.dav4android.DavResource.checkStatus(DavResource.java:291)
        at at.bitfire.dav4android.DavResource.put(DavResource.java:202)
        at at.bitfire.davdroid.syncadapter.SyncManager.uploadDirty(SyncManager.java:317)
        at at.bitfire.davdroid.syncadapter.SyncManager.performSync(SyncManager.java:147)
        at at.bitfire.davdroid.syncadapter.CalendarsSyncAdapterService$SyncAdapter.sync(CalendarsSyncAdapterService.java:68)
        at at.bitfire.davdroid.syncadapter.SyncAdapterService$SyncAdapter.onPerformSync(SyncAdapterService.java:85)
        at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)

Evolution says:

Failed to create an event in the calendar 'CalDAV : Manu_Christian' 
Cannot create calendar object: Object not found

cgogolin · 2016-11-27T17:51:38Z

With newly created calendars everything seems to work. Only those present during the update can not be edited anymore.

What is the best way to find out in which way the newly created calendars differ from the old ones?

DeepDiver1975 · 2016-11-28T11:38:38Z

What is the best way to find out in which way the newly created calendars differ from the old ones?

Please have a look in the database - let's start with:

select * from oc_calendars

cgogolin · 2016-11-28T12:10:23Z

I have uploaded the output of that command (shortened to only include the relevant users). The (newly created) shared calendar that works is Christian_Manu shared from cgogolin to manuela.mergel. The one that doesn't work (but worked before the upgrade) is Manu_Christian shared from manuela.mergel to cgogolin.

DeepDiver1975 · 2016-11-28T12:44:02Z

thx - can I ask you to the table contents of the oc_dav_shares table?

select * from oc_dav_shares where resourceid = 9;
select * from oc_dav_shares where resourceid = 23;

cgogolin · 2016-11-28T12:58:52Z

Here is the output:

mysql> select * from oc_dav_shares where resourceid = 9;
+----+---------------------------+----------+--------+------------+
| id | principaluri              | type     | access | resourceid |
+----+---------------------------+----------+--------+------------+
|  7 | principals/users/cgogolin | calendar |      2 |          9 |
+----+---------------------------+----------+--------+------------+
1 row in set (0.00 sec)

mysql> select * from oc_dav_shares where resourceid = 23;
+----+---------------------------------+----------+--------+------------+
| id | principaluri                    | type     | access | resourceid |
+----+---------------------------------+----------+--------+------------+
|  9 | principals/users/manuela.mergel | calendar |      2 |         23 |
+----+---------------------------------+----------+--------+------------+
1 row in set (0.00 sec)

DeepDiver1975 · 2016-11-28T13:11:05Z

hmmm ... nothing strange .....

raoulbhatia · 2016-11-29T13:18:47Z

I am affected as well.

cgogolin · 2016-12-04T12:55:52Z

To work around the problem I decided yesterday to copy over all entries from the dysfunctional calendar to the newly created one (export to .ics, then import, both with Evolution) and simply use the new calendar instead of the old one.

Unfortunately, after copying over all events, the new calendar now shows the same behavior as the old one. The person sharing the calendar can still create/edit/delete events normally, the person to which the calendar is shared can not do any of those anymore.

The errors shown by Evolution and Davdroid are the same as above.

I suspect that there is a problem with some of the calendar entries. How can I help out wich ones cause the problem? The number of entries is much too large to analyse them manually. Is there anything I could look for? Special characters or something?

cgogolin · 2016-12-04T13:22:10Z

Digging a little deeper reveals a another level of absurdity of this problem: Thunderbird with SOGo Connector 24.0.6 is able to write to the shared calendars using the account to which they were shared, but not, as explained above, Evolution mail or Davdroid.

cgogolin · 2016-12-04T13:38:54Z

I think this is a server issue, but have also opened a bug report with Davdroid to geht their opinion. You can see the full debug output of Davdroid here.

cgogolin · 2016-12-04T14:28:36Z

Another piece of potentially useful information (sorry for bringing them up one by one, I am not experienced with debugging ownclound): I get this error message repeaded many times in owncloud.log

{"reqId":"rDG6xl4h4Wp+ZxdzTeXa","remoteAddr":"90.170.253.225","app":"caldav","message":"Exception: {\"Message\":\"This recurrence rule does not generate any valid instances\",\"Exception\":\"Sabre\\\\VObject\\\\Recur\\\\NoInstancesException\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/CalDAV\\\/CalDavBackend.php(1352): Sabre\\\\VObject\\\\Recur\\\\EventIterator->__construct(Object(Sabre\\\\VObject\\\\Component\\\\VCalendar), 'oirerhq5m394857...')\\n#1 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/CalDAV\\\/CalDavBackend.php(658): OCA\\\\DAV\\\\CalDAV\\\\CalDavBackend->getDenormalizedData('BEGIN:VCALENDAR...')\\n#2 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/CalDAV\\\/CalendarObject.php(104): OCA\\\\DAV\\\\CalDAV\\\\CalDavBackend->updateCalendarObject('8', 'oirerhq5m394857...', 'BEGIN:VCALENDAR...')\\n#3 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1070): Sabre\\\\CalDAV\\\\CalendarObject->put('BEGIN:VCALENDAR...')\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(511): Sabre\\\\DAV\\\\Server->updateFile('calendars\\\/manue...', Resource id #75, NULL)\\n#5 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#6 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#7 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#8 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#9 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/caldav.php(83): Sabre\\\\DAV\\\\Server->exec()\\n#10 \\\/var\\\/www\\\/owncloud\\\/remote.php(164): require_once('\\\/var\\\/www\\\/ownclo...')\\n#11 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/vobject\\\/lib\\\/Recur\\\/EventIterator.php\",\"Line\":199,\"User\":\"manuela.mergel\"}","level":4,"time":"2016-12-03T18:19:52+00:00","method":"PUT","url":"\/owncloud\/remote.php\/caldav\/calendars\/manuela.mergel\/personal\/oirerhq5m394857stp7fti1j24%2540google.com.ics","user":"manuela.mergel"}

To me it looks as if that is what the server is saying when the client fails to edit the shared calendar.

daniell1 · 2016-12-20T11:24:45Z

I'm affected as well. I can confirm that this happens since version 9.1.2. Upgrading to 9.1.3 didn't fix it. The clients I'm using are Thunderbird 45.5.1 with Lightning 4.7.5.1 and DAVdroid 1.3.4.1. My server is running on Fedora with ownCloud shipped by Fedora. I already reported the issue there for documentation: https://bugzilla.redhat.com/show_bug.cgi?id=1405715

PS: Editing shared calendars via WebGUI is working.

cgogolin · 2016-12-20T11:39:14Z

I have one additional piece of information: Between users created after the update sharing of calendars seems to work normally.

Bilemma · 2016-12-28T13:36:52Z

I had the same problem - by now I did not update to owncloud 9.1.3.
I use DAVdroid 1.3.4.1 for syncing to android.

What worked for me today was changing the account details in DAVdroid to:

CalDAV/CardDAV path: /remote.php/dav/ (e.g. https://server.example/owncloud/remote.php/dav/)

(Found here: https://davdroid.bitfire.at/configuration/owncloud/ )

I don't understand why this helps, but it does for me. I keep you updated, if further errors occur later.

daniell1 · 2016-12-29T15:11:03Z

Hi. Thanks for sharing this with us. It solves the problem in Thunderbird Lightning as well.

PS: The sharing URL in the WebGui is correct too.

simogeo · 2017-01-05T13:09:59Z

Same problem here after 9.1.3 upgrade ....

Here is the output of select * from oc_dav_shares :

Just wondering if access value '3' is correct or not .....

and I can see the following log :

Exception: {"Message":"HTTP/1.1 404 Node with name 'commun-intermezzo_shared_by_simon' could not be found","Exception":"Sabre\DAV\Exception\NotFound","Code":0,"Trace":"#0 /var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php(796): OCA\DAV\Connector\Sabre\DavAclPlugin->checkPrivileges('calendars/laure...', '{DAV:}bind')\n#1 [internal function]: Sabre\DAVACL\Plugin->beforeBind('calendars/laure...')\n#2 /var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#3 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(1021): Sabre\Event\EventEmitter->emit('beforeBind', Array)\n#4 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php(523): Sabre\DAV\Server->createFile('calendars/laure...', Resource id #64, NULL)\n#5 [internal function]: Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#6 /var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#7 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(459): Sabre\Event\EventEmitter->emit('method:PUT', Array)\n#8 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#9 /var/www/owncloud/apps/dav/appinfo/v1/caldav.php(83): Sabre\DAV\Server->exec()\n#10 /var/www/owncloud/remote.php(164): require_once('/var/www/ownclo...')\n#11 {main}","File":"/var/www/owncloud/apps/dav/lib/Connector/Sabre/DavAclPlugin.php","Line":62,"User":"laurent"}

Thanks for your help

daniell1 · 2017-01-05T13:31:34Z

With which URL are you accessing the calendars? Are you accessing them like Bilemma described three posts above? I'm on 9.1.3 as well and it helped.

simogeo · 2017-01-05T15:20:38Z

I've tried replacing the full url by https://server.example/owncloud/remote.php/dav/

I also tried the proposed fix here : https://doc.owncloud.org/server/9.0/admin_manual/issues/general_troubleshooting.html#service-discovery-label

settings url as 'https://server.example/' and adding 'Redirect 301 /.well-known/caldav /owncloud/remote.php/dav' to .htaccess with no success ....

any clue ?

hessijames79 · 2017-01-25T21:41:40Z

Same problem here with Owncloud 9.1.3 and URL http://$host/owncloud/remote.php/dav/ (as well as the old caldav ones...)

simogeo · 2017-01-27T08:58:28Z

someone, any news regarding this bug ? any fix to provide ?

raoulbhatia · 2017-01-27T09:52:12Z

I suppose the only resolution is updating to Nextcloud?
See nextcloud/server#2402 Comment #263572190

simogeo · 2017-01-27T10:19:27Z

And, is there somewhere a migration howto ?

raoulbhatia · 2017-01-27T10:24:27Z

And, is there somewhere a migration howto ?

https://help.nextcloud.com/t/migrating-from-owncloud-to-nextcloud/551 might be a good start. Raoul

simogeo · 2017-01-27T10:26:07Z

Thanks for this. Does owncloud client still works with nextcloud server ?

hessijames79 · 2017-01-28T11:18:45Z

I managed to get it solved on my system.

I am using the Debian package of Owncloud without any modifications. Hence, owncloud is located at http://HOST/owncloud. I added the following lines to the VirtualHost in /etc/apache2/sites-available/000-default:
Redirect 301 /.well-known/carddav /owncloud/remote.php/dav
Redirect 301 /.well-known/caldav /owncloud/remote.php/dav
After restarting Apache, adding events to a shared calendar worked.

raoulbhatia · 2017-01-28T17:19:17Z

@simogeo Please do a little research by yourself.
There is extensive documentation available via your favorite search engine.

Thanks,
Raoul

sumnerboy12 · 2017-01-28T20:25:28Z

I am seeing this too (on v9.1.3) and noticed this in my Apache2 logs;

When creating an event using the calendar owner (me) it works fine;

192.168.10.1 - ben [29/Jan/2017:09:16:47 +1300] "PUT /owncloud/remote.php/caldav/calendars/ben/family/987f8453-9bcb-4e4a-b41e-83f6c3157426.1485634607487.ics HTTP/1.1" 201 1129 "-" "CalDAV-Sync/0.4.27 (samsung; heroltexx; Android 6.0.1; en_NZ; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"

But when doing the same thing for a shared calendar (i.e. same calendar but different user via a share);

192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/a5205fc6-0453-47f8-bcc1-01baa329f662.1485634432282.ics HTTP/1.1" 404 1398 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/bd15e605-8c20-4c47-b9c5-ee1a987a83c6.1485634432447.ics HTTP/1.1" 404 1400 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/52a39568-8db9-495b-9cb1-c26acdbdb5d2.1485634432617.ics HTTP/1.1" 404 1396 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/1d50fc43-4335-4abd-a1a9-479faec1a590.1485634432764.ics HTTP/1.1" 404 1402 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/d8c513e1-9f15-4466-bbba-f1b474fa3b41.1485634432916.ics HTTP/1.1" 404 1406 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/3c9d170d-539f-4c16-bdc8-6ae2c6cb756c.1485634433074.ics HTTP/1.1" 404 1394 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:58 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/8cb18519-9354-474a-b4a9-345d6379ec09.1485634433268.ics HTTP/1.1" 404 1396 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"

I am no expert but wondered if this might help the developers looking at this?

Looks like the request to create the event is getting a 404 for the shared URL (i.e. /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/) but works fine for direct (non-shared) access (/owncloud/remote.php/caldav/calendars/ben/family/).

Would love to get this working as currently anything my wife adds to the family calendar is not synchronised and thus no one else knows about!!

daniell1 · 2017-01-28T22:35:42Z

Seems like you are not using the correct URLs. Have you either configured your clients as described here #26667 (comment) or your server as described in the troubleshooting guide that was linked in this comment #26667 (comment) ?

sumnerboy12 · 2017-01-29T01:35:17Z

Thanks guys - I had provisioned my Android phones using CALDav-Sync and entering <servername>/owncloud as the URL. It then found the caldav URL and I could see/edit my own calendars, so just thought it was ok. But this meant shared calendars couldn't be edited. By explicitly entering <servername>/owncloud/remote.php/dav everything seems to be working now. Thanks again!

raoulbhatia · 2017-01-30T08:59:24Z

After some additional debugging, I also figured out that the issue lies within the URL configuration, i.e.

Old: /remote.php/caldav/[...]
New: /remote.php/dav/[...]

I have no idea why there is a difference between direct and shared calendars.
Nevertheless, I've also completed my transition to Nextcloud this weekend.

Last but not least, I think that one would be able to create a (temporary) workaround by using the rewrite capabilities of the webserver.
I.e. for nginx; incomplete & not fully tested:

rewrite ^/?.well-known/carddav /remote.php/dav permanent;
rewrite ^/?.well-known/caldav /remote.php/dav permanent;

rewrite ^/remote.php/carddav/addressbooks(.*) /remote.php/dav/addressbooks/users$1 permanent;
[...]

simogeo · 2017-01-30T11:05:24Z

I'll also switch to nextcloud ... thanks

jens-maus · 2017-03-28T07:48:12Z

After upgrading to 9.1.x I was suffering from the exact same problem as documented here. To solve my issues with not being able to edit/delete shared calendar entries I added the following workaround to my nginx config:

# workaround for bug in 9.1.x
rewrite ^/.well-known/carddav /remote.php/dav/ permanent;
rewrite ^/.well-known/caldav /remote.php/dav/ permanent;
rewrite ^/remote.php/caldav/calendars/(.*) /remote.php/dav/calendars/$1 permanent;

This immediately solved my issues and I am able to edit shared calendar entries again. However, if this issue is really already solved in nextcloud but not on owncloud I really have to evaluate to switch to NextCloud soon.

nobswolf · 2017-04-11T04:45:16Z

same issue in 8.2.9 , BTW

edit: not exactly the same as it seems: even in a new non-shared calendar it does not work

DeepDiver1975 · 2017-05-17T06:58:00Z

This was fixed with 10.0.1 - see #27792

lock · 2019-07-31T21:01:28Z

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

PVince81 added the comp:caldav label Nov 22, 2016

DeepDiver1975 self-assigned this Nov 28, 2016

DeepDiver1975 added this to the 9.2 milestone Nov 28, 2016

raoulbhatia mentioned this issue Nov 29, 2016

DAV: Unable to put an .ics file to a shared calendar (calendar v1.4.1) nextcloud/server#2402

Closed

DeepDiver1975 closed this as completed May 17, 2017

DeepDiver1975 modified the milestones: 10.0.1, 10.0 May 17, 2017

ownclouders added the status/STALE label Dec 21, 2017

skriesch mentioned this issue Jun 13, 2018

event from iPhone won't be synced to ownCloud Calendar owncloud/calendar#787

Closed

ownclouders mentioned this issue Jul 7, 2018

Adding calendar or reminder via CalDAV on macOS results in SQL error #32007

Closed

lock bot locked as resolved and limited conversation to collaborators Jul 31, 2019

Shared calendars not editable via caldav #26667

Shared calendars not editable via caldav #26667

Comments

romris commented Nov 21, 2016 • edited by DeepDiver1975 Loading

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration

PVince81 commented Nov 22, 2016

cgogolin commented Nov 24, 2016

cgogolin commented Nov 27, 2016

DeepDiver1975 commented Nov 28, 2016

cgogolin commented Nov 28, 2016 • edited Loading

DeepDiver1975 commented Nov 28, 2016

cgogolin commented Nov 28, 2016

DeepDiver1975 commented Nov 28, 2016

raoulbhatia commented Nov 29, 2016

cgogolin commented Dec 4, 2016

cgogolin commented Dec 4, 2016

cgogolin commented Dec 4, 2016

cgogolin commented Dec 4, 2016 • edited Loading

daniell1 commented Dec 20, 2016

cgogolin commented Dec 20, 2016

Bilemma commented Dec 28, 2016

daniell1 commented Dec 29, 2016

simogeo commented Jan 5, 2017 • edited Loading

daniell1 commented Jan 5, 2017

simogeo commented Jan 5, 2017

hessijames79 commented Jan 25, 2017 • edited Loading

simogeo commented Jan 27, 2017

raoulbhatia commented Jan 27, 2017

simogeo commented Jan 27, 2017

raoulbhatia commented Jan 27, 2017 via email • edited Loading

simogeo commented Jan 27, 2017

hessijames79 commented Jan 28, 2017 • edited Loading

raoulbhatia commented Jan 28, 2017

sumnerboy12 commented Jan 28, 2017

daniell1 commented Jan 28, 2017

sumnerboy12 commented Jan 29, 2017

raoulbhatia commented Jan 30, 2017

simogeo commented Jan 30, 2017

jens-maus commented Mar 28, 2017

nobswolf commented Apr 11, 2017 • edited Loading

DeepDiver1975 commented May 17, 2017

lock bot commented Jul 31, 2019

romris commented Nov 21, 2016 •

edited by DeepDiver1975

Loading

cgogolin commented Nov 28, 2016 •

edited

Loading

cgogolin commented Dec 4, 2016 •

edited

Loading

simogeo commented Jan 5, 2017 •

edited

Loading

hessijames79 commented Jan 25, 2017 •

edited

Loading

raoulbhatia commented Jan 27, 2017 via email •

edited

Loading

hessijames79 commented Jan 28, 2017 •

edited

Loading

nobswolf commented Apr 11, 2017 •

edited

Loading