Calendar bug for disabled calendars in 3.4 ea

Bug Reports
,
#21

Hi I was checking when I installed 4.2. And it occurred right in front of my eyes when I had unticked the calendars and came back to view it.

A few days ago I tested again and it didnt occur right away, but in a few hours without my interactions, it had reset the calendar view.

Näyttökuva_20210926_003
Näyttökuva_20210926_0031080×2520 805 KB

Näyttökuva_20210926_002
Näyttökuva_20210926_0021080×2520 609 KB

Näyttökuva_20210926_004
Näyttökuva_20210926_0041080×2520 848 KB

From the screeshots times we can see that it occurred between 16:37 and 20:20 so in under 4 hours.

Is it storing the calendar view settings right away or on app closing? Could it be that Oom or smth kills the view and the settings are not stored?

#22

Could it be that Oom or smth kills the view and the settings are not stored?

No actually, they are stored right away.

Still thinking about what could trigger this behaviour…

#23

I am sorry I cannot reproduce it. On my phones it ONLY appears at the main exchange calendar (subcalendars work), linked over my domain via DNS to Office365.
I am moving away from MSFT anyway. I think it is an Office365 problem in my case, I will try it with an exchange account to mailbox.org now and reply then.

EDIT: No, it’s not an Office main cal issue, happens on all cals including subcals every restart.

#24

Yes, for Exchange, it’s a “feature”. The sync is imposing the visibility declared on the server (previously, it was not the case, the visibility bit was not honored). For Google and CalDAV, the visibility is not transmitted, or at least not read and thus not taken into account.

That being said, it could be discussed if it’s wise to follow the visibility information sent by Exchange servers… But the Exchange plugin is closed source and I cannot do anything to it.

See https://github.com/sailfishos/contactsd/pull/1, I’ve identified at least one code path that can lead to visibility reset even for Google accounts. But I cannot figure out how it is related to @miqu description of his issue.

#25

From my point of view I totally understand the rationale behind having server visibility separate from device visibility. From server usually means a web UI of somekind that you use to see your calendar. So I would see that as separate from devices. Though I do understand the rationale behind the other way also that there is just a calendar and its subvisibility. Where you sync it doesnt matter. But it does. :slight_smile:

#26

Thx for your reply. Another point I’ll move to CalDAV. Having many different devices with different purposes, this “feature” is not wise :wink:

Another thing. Is a week calendar or 3-5 days calendar really so hard to create?

SFOS 4.5 feedback thread
#27

About the Exchange “feature”, as I said, it may be changed by Jolla. They didn’t enable it actually. It was a by-product of some code simplification @flypig and I did on calendar visibility handling. Exchange is flipping the visibility bit of calendars and as far as I know it’s the only sync plugin that does it. But this bit was itself ignored and superceeded by a QSetting (or something similar) in the QML bindings. This added a lot of boiler plate in the QML bindings and any C++ code handling calendars was even not aware of it. So we removed the QSetting (it was the same for colours), which made the “feature” of Exchange to “appear”. The same treatment than the one that has been decided for colours in the sync plugins could be applied here in the Exchange sync plugin : flip the calendar visibility on the phone only if there is a visibility change on the server, otherwise keep the user choice on device.

Another thing. Is a week calendar or 3-5 days calendar really so hard to create?

In my opinion, it’s not difficult. In a quick thought about it, it seems that every pieces are already available in the QML bindings to get the information (the AgendaModel is flexible enough to get events for a week). It’s mainly a question of design and actually writing the QML files for it.

I’m quite reluctant in doing it myself for license reason. Jolla-calendar source code is proprietary and I would loose all written code. Fixing an issue in the QML files here and there is fine, doing a minor addition of some lines of QML that can be redone easily is still alright. But write an extensive length of QML without the possibility to reuse it later is a no go.

1 Like
#28

thanks for your response! I wish I had time for coding again, my skills stopped at pascal / delphi and C (without+) and I have zero time as a selfemployed with family.
Couldn’t Rostelkom pay you some 10000-100000 bucks (€£$) for making a week view? :wink:

#29

Couldn’t Rostelkom pay you some 10000-100000 bucks (€£$) for making a week view?

Actually no, at least they didn’t propose : -) …

All my contributions are done on my free time without being paid. That’s why I try to focus on open source parts only. It’s kind of sustainable coding : like that code can survive any bankruptcy or change in strategy. I wouldn’t be interested in writing proprietary code for money. I’m lucky to have a (nice) job for that (where created code is open source).

It’s completely off-topic, but the suggestion to implement a week view by the community hitched my curiosity and I will investigate it. And find a way to have it with an open source license…

3 Likes