-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Allow DAV Object properties #30368
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
Allow DAV Object properties #30368
Conversation
| public function run(IOutput $output) { | ||
| $query = $this->connection->getQueryBuilder(); | ||
| $updated = $query->delete('properties') | ||
| ->where($query->expr()->eq('propertyname', $query->createNamedParameter(self::RESOURCE_TYPE_PROPERTY))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important note : I chose to delete only {DAV:}resourcetype properties because they were the ones involved in the calendar issue, but there might be more concerned propertynames.
I didn't want to directly remove the condition on propertyname in case there's some legitimate Object propertyvalues, (which seems however unlikely).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found two extra property names affected:
{http://calendarserver.org/ns/}me-card{urn:ietf:params:xml:ns:caldav}schedule-calendar-transp
aa2bfe9 to
56bafc3
Compare
56bafc3 to
82a14e6
Compare
|
I think this is a better way to handle things than converting to string #30771 |
82a14e6 to
175fb56
Compare
The current implementation only saves them as string. It seems they can be more complex than that, and that objects were saved directly. You may find such objects saved in some production databases by executing: ```sql SELECT * from oc_properties where propertyvalue = 'Object'; ``` This commit adds a repair job to clean all of these "broken" properties values, adds a new database column to save the type of the property, and handles converting from and to correct values. Implementation is very similar to SabreDAV's own PDO backend: https://github.com/nextcloud/3rdparty/blob/4921806dfb1c5c309eac60195ed34e2749baf3c1/sabre/dav/lib/DAV/PropertyStorage/Backend/PDO.php Signed-off-by: Thomas Citharel <[email protected]>
175fb56 to
bd8b213
Compare
PVince81
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, old known issue 👍
Also will likely solve issues with Oracle when storing complex props as I rembember issues there
|
25 only as it adds a new column and might be an expensive upgrade |
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <[email protected]>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <[email protected]>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <[email protected]>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <[email protected]>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <[email protected]>
The current implementation only saves them as string. It seems they can be more complex than that, and that objects were saved directly.
You may find such objects saved in some production databases by executing:
This seems to cause issues in some particular cases (nextcloud/calendar#3551) like the calendar trashbin because of things like this and (apparently ?) Apple devices:
server/apps/dav/lib/CalDAV/CalDavBackend.php
Lines 3208 to 3211 in 0b01103
This commit adds a repair job to clean all of these "broken" properties values, adds a new database column to save the type of the property, and handles converting from and to correct values.
Implementation is very similar to SabreDAV's own PDO backend: https://github.com/nextcloud/3rdparty/blob/4921806dfb1c5c309eac60195ed34e2749baf3c1/sabre/dav/lib/DAV/PropertyStorage/Backend/PDO.php
Fixes nextcloud/calendar#3858 (comment)