New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing databasefield "publicuri" in oc_dav_shares after upgrade to 10.0.0 (stable) from 9.1.5 #27754

Closed
mkeller0815 opened this Issue Apr 27, 2017 · 17 comments

Comments

Projects
None yet
10 participants
@mkeller0815

mkeller0815 commented Apr 27, 2017

Using ubuntu 14.04 and the official repo:
http://download.owncloud.org/download/repositories/stable/Ubuntu_14.04/

I upgraded from 9.1.5 to 10.0.0 (stable).
I also upgraded to php5.6.

The "occ upgrade" went fine without any issues. I had also run the "repair" command to possibly fix the issue.

The problem is the calendar app. After upgrading to the version for 10.0.0. it shows no calendars, only the rotating "load icon".
Checking the ajax-calls it seems that the call to "/remote.php/dav/calendars/mario/" fails with

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Doctrine\DBAL\Exception\InvalidFieldNameException</s:exception>
  <s:message>An exception occurred while executing 'SELECT `publicuri` FROM `oc_dav_shares` WHERE (`resourceid` = ?) AND (`access` = ?)' with params ["1", 4]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'publicuri' in 'field list'</s:message>
</d:error>

checking the database this field seems to be missing:

mysql> describe oc_dav_shares;                                                                                                                                        │···
+--------------+---------------------+------+-----+---------+----------------+                                                                                        │···
| Field        | Type                | Null | Key | Default | Extra          |                                                                                        │···
+--------------+---------------------+------+-----+---------+----------------+                                                                                        │···
| id           | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |                                                                                        │···
| principaluri | varchar(255)        | YES  | MUL | NULL    |                |                                                                                        │···
| type         | varchar(255)        | YES  |     | NULL    |                |                                                                                        │···
| access       | smallint(6)         | YES  |     | NULL    |                |                                                                                        │···
| resourceid   | int(10) unsigned    | NO   |     | NULL    |                |                                                                                        │···
+--------------+---------------------+------+-----+---------+----------------+                                                                                        │···
5 rows in set (0.00 sec)       

I found an migration-Script in

apps/dav/appinfo/Migrations/Version20170116150538.php

that should add this field, but it seems that is was not running or it hasn'tnt added the field.

@dennisbaaten

This comment has been minimized.

Show comment
Hide comment
@dennisbaaten

dennisbaaten Apr 27, 2017

If you add the field manually as stated in the php file (the same as "principaluri") then the calander app seems working; calendar items are shown as before.
However, sychronisation with CalDav Syncronizer still seems broken.
What should be the content of this field? Is that specified anywhere?

dennisbaaten commented Apr 27, 2017

If you add the field manually as stated in the php file (the same as "principaluri") then the calander app seems working; calendar items are shown as before.
However, sychronisation with CalDav Syncronizer still seems broken.
What should be the content of this field? Is that specified anywhere?

@CRCinAU

This comment has been minimized.

Show comment
Hide comment
@CRCinAU

CRCinAU Apr 27, 2017

Fixed this with:
ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri;

CRCinAU commented Apr 27, 2017

Fixed this with:
ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri;

@VicDeo VicDeo referenced this issue Apr 27, 2017

Merged

Create missing field in dav_shares #27756

1 of 9 tasks complete
@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Apr 27, 2017

Member

@mkeller0815 please test #27756

Member

VicDeo commented Apr 27, 2017

@mkeller0815 please test #27756

@Niduroki

This comment has been minimized.

Show comment
Hide comment
@Niduroki

Niduroki Apr 27, 2017

Member

@dennisbaaten I don't know if it's mentioned anywhere in the changelog, but by the looks of it the dav-urls have changed.
I fixed my DavDroid installation by recreating my account using https://cloud.example.com/remote.php/dav/ as base url instead of just https://cloud.example.com/

Member

Niduroki commented Apr 27, 2017

@dennisbaaten I don't know if it's mentioned anywhere in the changelog, but by the looks of it the dav-urls have changed.
I fixed my DavDroid installation by recreating my account using https://cloud.example.com/remote.php/dav/ as base url instead of just https://cloud.example.com/

@CRCinAU

This comment has been minimized.

Show comment
Hide comment
@CRCinAU

CRCinAU Apr 27, 2017

I was just working on the Davdroid issue too....
These redirects work:
Redirect 301 /.well-known/carddav /remote.php/dav
Redirect 301 /.well-known/caldav /remote.php/dav

CRCinAU commented Apr 27, 2017

I was just working on the Davdroid issue too....
These redirects work:
Redirect 301 /.well-known/carddav /remote.php/dav
Redirect 301 /.well-known/caldav /remote.php/dav

@dennisbaaten

This comment has been minimized.

Show comment
Hide comment
@dennisbaaten

dennisbaaten Apr 27, 2017

Correct! Just discovered this myself. The URL-part "caldav" changed to "dav" (in case of the Calendar)

dennisbaaten commented Apr 27, 2017

Correct! Just discovered this myself. The URL-part "caldav" changed to "dav" (in case of the Calendar)

@CRCinAU

This comment has been minimized.

Show comment
Hide comment
@CRCinAU

CRCinAU Apr 27, 2017

It looks like groups may have broken with DavDroid + OC 10.0.0 as well.... but I need to sleep :\

CRCinAU commented Apr 27, 2017

It looks like groups may have broken with DavDroid + OC 10.0.0 as well.... but I need to sleep :\

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Apr 28, 2017

Member

Correct! Just discovered this myself. The URL-part "caldav" changed to "dav" (in case of the Calendar)

dav was added the old urls are still valid - you can still use caldav.

Member

DeepDiver1975 commented Apr 28, 2017

Correct! Just discovered this myself. The URL-part "caldav" changed to "dav" (in case of the Calendar)

dav was added the old urls are still valid - you can still use caldav.

@mkeller0815

This comment has been minimized.

Show comment
Hide comment
@mkeller0815

mkeller0815 Apr 28, 2017

@VicDeo I tried to patch directly from you commit, but it fails in several chunks as well as that in my installation the database.xml file is missing.
I have nothing changed by hand before, just updated from the regular repos.
I just added the field manually in the database. Calendars are now shown and I also could add a new entry on my iPhone and the entry showed up in the web-calendar. I will have an eye on this and hope your fix will make it into the next version.
Thanks to all for the help and you effort on this.
Mario.

mkeller0815 commented Apr 28, 2017

@VicDeo I tried to patch directly from you commit, but it fails in several chunks as well as that in my installation the database.xml file is missing.
I have nothing changed by hand before, just updated from the regular repos.
I just added the field manually in the database. Calendars are now shown and I also could add a new entry on my iPhone and the entry showed up in the web-calendar. I will have an eye on this and hope your fix will make it into the next version.
Thanks to all for the help and you effort on this.
Mario.

@simsasaile

This comment has been minimized.

Show comment
Hide comment
@simsasaile

simsasaile Apr 28, 2017

please test #27756

Patch didn't work for me. Still can't use the calendar app.

UPDATE: manual removing and reinstalling the app (probably together with the patch) fixed it now.

simsasaile commented Apr 28, 2017

please test #27756

Patch didn't work for me. Still can't use the calendar app.

UPDATE: manual removing and reinstalling the app (probably together with the patch) fixed it now.

@ichEben

This comment has been minimized.

Show comment
Hide comment
@ichEben

ichEben Apr 28, 2017

Contributor

Also got this problem after upgrading from 9 to 10.
The above fix:

ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri;

worked for me.

Contributor

ichEben commented Apr 28, 2017

Also got this problem after upgrading from 9 to 10.
The above fix:

ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri;

worked for me.

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Apr 28, 2017

Member

@mkeller0815 my commit doesn't change database.xml
It consists of
1 new file apps/dav/appinfo/Migrations/Version20170427182800.php
1 changed file apps/dav/appinfo/info.xml the only change here is a version number. It is bumped to start migration

Member

VicDeo commented Apr 28, 2017

@mkeller0815 my commit doesn't change database.xml
It consists of
1 new file apps/dav/appinfo/Migrations/Version20170427182800.php
1 changed file apps/dav/appinfo/info.xml the only change here is a version number. It is bumped to start migration

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Apr 28, 2017

Member

For all reading this: please use +😄 button to express your happiness after successful manual DB patching. Fixing with a direct database query is just a workaround and doesn't solve the issue for other users in future.

But I would be very thankful for testing pull request #27756 first and leaving some feedback in the pull request

Member

VicDeo commented Apr 28, 2017

For all reading this: please use +😄 button to express your happiness after successful manual DB patching. Fixing with a direct database query is just a workaround and doesn't solve the issue for other users in future.

But I would be very thankful for testing pull request #27756 first and leaving some feedback in the pull request

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 30, 2017

Just a note to the "changed" CalDAV / CardDAV URL and the part here #27754 (comment):

dav was added the old urls are still valid - you can still use caldav.

There are more and more people reporting that the old URLs are not working anymore. There is now a new bugreport about that in #27778

If anyone can provide more info please post them there.

ghost commented Apr 30, 2017

Just a note to the "changed" CalDAV / CardDAV URL and the part here #27754 (comment):

dav was added the old urls are still valid - you can still use caldav.

There are more and more people reporting that the old URLs are not working anymore. There is now a new bugreport about that in #27778

If anyone can provide more info please post them there.

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 May 3, 2017

Member

fixed with #27756

Member

DeepDiver1975 commented May 3, 2017

fixed with #27756

@Sequential-circuits

This comment has been minimized.

Show comment
Hide comment
@Sequential-circuits

Sequential-circuits May 20, 2017

I just upgraded to version 10 and can't get the calendar icon to show up. Tried the ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri; command listed above but the database already contained that field. So far the experience has been quite negative: it would have been useful to inform for example that one needs to upgrade PHP and that this process is itself nightmarish.

Sequential-circuits commented May 20, 2017

I just upgraded to version 10 and can't get the calendar icon to show up. Tried the ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri; command listed above but the database already contained that field. So far the experience has been quite negative: it would have been useful to inform for example that one needs to upgrade PHP and that this process is itself nightmarish.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 20, 2017

@Sequential-circuits

Tried the ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri; command listed above but the database already contained that field.

Then i think its unrelated to this issue.

it would have been useful to inform for example that one needs to upgrade PHP

The release notes contains that information.

https://doc.owncloud.org/server/10.0/admin_manual/release_notes.html

Personally i'm always having a look at release notes of a software i'm using before i'm doing a upgrade to a new major release.

If the release notes pointed out above is not that clear you can also request more clear notes about that at https://github.com/owncloud/documentation/issues

and that this process is itself nightmarish.

IMHO this is not the job of a web application. If the process to upgrade PHP on your used linux distro is nightmarish then you might want to complain to your distro.

ghost commented May 20, 2017

@Sequential-circuits

Tried the ALTER TABLE oc_dav_shares ADD publicuri VARCHAR(255) NOT NULL AFTER principaluri; command listed above but the database already contained that field.

Then i think its unrelated to this issue.

it would have been useful to inform for example that one needs to upgrade PHP

The release notes contains that information.

https://doc.owncloud.org/server/10.0/admin_manual/release_notes.html

Personally i'm always having a look at release notes of a software i'm using before i'm doing a upgrade to a new major release.

If the release notes pointed out above is not that clear you can also request more clear notes about that at https://github.com/owncloud/documentation/issues

and that this process is itself nightmarish.

IMHO this is not the job of a web application. If the process to upgrade PHP on your used linux distro is nightmarish then you might want to complain to your distro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment