Closed cm-schl closed 2 years ago
Thanks for the bug report.
As a sidenote, we will probably use RFC9073's STYLED-DESCRIPTION
for rich text formatting if we ever have this feature (see #3234), not ALTREP
.
The bug comes from the data being inconsistent now. When the description changes, the parameters of the DESCRIPTION
property are no longer valid.
The expected minimal behavior is that NextCloud, when writing the DESCRIPTION
property, also deletes all parameters of the DESCRIPTION
property, which are now outdated.
So, the fix here should be simple: When setting DESCRIPTION
, just delete all parameters of DESCRIPTION
property, including the ALTREP
parameter. That avoids the bug.
DESCRIPTION;ALTREP="data:text/html,%3Cbody%3Etest%20one%3C%2Fbody%3E":test one
DESCRIPTION;ALTREP="data:text/html,%3Cbody%3Etest%20one%3C%2Fbody%3E":test two
DESCRIPTION:test two
Given that the property parameters describe the property (not the whole calendar item, just this property), and the property changed, it's reasonable to assume that the parameters which described the old property are no longer valid.
The same issue comes with X-ALT-DESC, which is used by other clients like Outlook and eM-Client to add an HTML representation of the description value. Would it be possible to delete the field, too, once the description is changed in Nextlcoud?
This should be fixed in #3924. All parameters should be deleted upon modification of the description. Can you give exact reproduction steps or excerpts from ics files?
@Gorendal Could you file a new ticket about that, and mention the new ticket number here?
While it's the same symptom, the cause is different, because ALTREP is a "parameter" of the modified DESCRIPTION property, whereas X-ALT-DESC is a completely different property. It needs a different fix.
@Gorendal @benbucksch Please refer to #4744.
@st3iny @benbucksch is there still something to be done from my side? Sorry, I am new to GitHub. So I haven't got the complete picture how this all works yet.
@Gorendal Possibly in reaction to your comment, @st3iny filed a new ticket #4744, which captures the problem that you raised. (It is a different problem than this ticket here, and this ticker here is already fixed, therefore it needed a new ticket.)
Good news is that #4744 was already fixed by @st3iny, so the problem you mentioned should be fixed now. It was even backported to NextCloud 3.5.x and 4.1.x.
You can test the next NextCloud release, whether it fixes your issue. Otherwise, there's nothing more to do. Any comments should be posted to #4744.
@benbucksch Sounds great. I am happy to test it. I just checked my Nextlcloud instance and it anyway offers an update to 25.0.2. So my current Calendar version is 4.1.0.
However: The behaviour still seems to stay the same after changing the description of an appointment in Nextcloud. The connected client "eM-Client" still logs the X-ALT-DESC field in the following VEVENT received from Nextcloud:
SUMMARY:Test Meeting 1 DESCRIPTION:first line added in eM-Client\nsecond line added in eM-Client\n third line added in Nextcloud\nfourth line added in Nextcloud X-ALT-DESC;FMTTYPE=text/html:<html><head><style id="css_styles">blockquote. cite { margin-left: 5px\; margin-right: 0px\; padding-left: 10px\; padding- right:0px\; border-left: 1px solid #cccccc }\nblockquote.cite2 {margin-left : 5px\; margin-right: 0px\; padding-left: 10px\; padding-right:0px\; border -left: 1px solid #cccccc\; margin-top: 3px\; padding-top: 0px\; }\na img { border: 0px\; }\nli[style='text-align: center\;']\, li[style='text-align: c enter\; ']\, li[style='text-align: right\;']\, li[style='text-align: right\ ; '] { list-style-position: inside\;}\nbody { font-family: Segoe UI\; font -size: 12pt\; } \n.quote { margin-left: 1em\; margin-right: 1em\; border- left: 5px #ebebeb solid\; padding-left: 0.3em\; }</style></head><body>first line added in eM-Client<div>second line added in eM-Client</div></body></h tml>
I wonder if I can check somehow the Nextcloud files on my server, if st3iny's fix is already available? I tried to locate the modified file "src/store/calendarObjectInstance.js" on my server but were not successful. Any idea?
@Gorendal As mentioned above, please make your comments at #4744, not here, as it's offtopic here. Thank you. Regarding installing the fix, you could ask on the help forums.
@Gorendal The fix is yet to be released. It will most likely be included in v4.1.1 and any later version.