Mozilla 도움말 검색

고객 지원 사기를 피하세요. 저희는 여러분께 절대로 전화를 걸거나 문자를 보내거나 개인 정보를 공유하도록 요청하지 않습니다. "악용 사례 신고"옵션을 사용하여 의심스러운 활동을 신고해 주세요.

자세히 살펴보기

CardDAV-Calendar fault detection of conflicts; strange acting with conflict handling

  • 1 답장
  • 0 이 문제를 만남
  • 1 보기
  • 최종 답변자: RalfK

more options

Hello,

interesting behavior with a CalDaV calendar entry/date.

Scenario: Create a calendar-entry (date) with an alarm-setting (1h before...). Wait until the new entry is synced to the CalDAV server, in my case a Nextcloud. Close TB. Got to the Nextcloud calendar, or to and other client with that CalDAV Calendar, and remove the alarm, I do frequently in case the date paste... Start TB. After sync of the calendar, TB is telling you, that the date was changed at the server and asked "how to handle the detected conflict" (see screenshot). But 1. it isn't a conflict, just a normal change, which should change the local, "old" date 2. acting on the conflict resolution by pressing the button "Skip changes, load new" (Änderungen verwerfen und neu laden), I'm expecting to get the server version exchanging the local, old one... It does not: The local version will stay with the alarm. These date will not sync to server until TB is restarted. The alarm is now back on the server.

If the alarm is removed at the server (or on another client) while TB is running, the alarm is removed locally as "normal" change by synchronization...

I guess it is a bug!?

I'm using TB Version 128.4.3esr; build-id: 20241108210256 on Windows 11 (64bit). But this is also with TB under Linux (ubuntu, mint)

Gruss Ralf

Hello, interesting behavior with a CalDaV calendar entry/date. Scenario: Create a calendar-entry (date) with an alarm-setting (1h before...). Wait until the new entry is synced to the CalDAV server, in my case a Nextcloud. Close TB. Got to the Nextcloud calendar, or to and other client with that CalDAV Calendar, and remove the alarm, I do frequently in case the date paste... Start TB. After sync of the calendar, TB is telling you, that the date was changed at the server and asked "how to handle the detected conflict" (see screenshot). But 1. it isn't a conflict, just a normal change, which should change the local, "old" date 2. acting on the conflict resolution by pressing the button "Skip changes, load new" (Änderungen verwerfen und neu laden), I'm expecting to get the server version exchanging the local, old one... It does not: The local version will stay with the alarm. These date will not sync to server until TB is restarted. The alarm is now back on the server. If the alarm is removed at the server (or on another client) while TB is running, the alarm is removed locally as "normal" change by synchronization... I guess it is a bug!? I'm using TB Version 128.4.3esr; build-id: 20241108210256 on Windows 11 (64bit). But this is also with TB under Linux (ubuntu, mint) Gruss Ralf
첨부된 스크린샷

모든 댓글 (1)

more options

At least "detecting a conflict" seems to be gone with version 128.5.1esr...

도움이 되셨습니까?

질문하기

글에 답글을 달기 위해서는 계정으로 로그인해야만 합니다. 계정이 아직 없다면 새로운 질문을 올려주세요.