Yes. All dialogs have two buttons for closing (sometimes it's Close, sometimes Cancel). I also don't think that Share is important enough to be a separate button.

Because jsTimezoneDetect is not very active project I decided to add a workaround on PHP side. Fixed in https://github.com/roundcube/roundcubemail/commit/36485dfc345ad724f08eaa7ea30c3cc88e48a00d.

This has been fixed a few days ago. Not yet deployed at beta.kolabnow.com

Well, this is how it was designed, so you focus on finding availability not changing the time or duration. These fields are there for an informative purpose of displaying currently selected time slot. Maybe the time inputs could be editable or maybe there should be some duration input. Or maybe the slot selector above could be extendable horizontally.

Fixed. Though, there are other similar issues, e.g. with toolbar menu. We probably should not support such view resizing. I'd say it's a rare situation. I guess it's more a temporal situation, you don't want to switch to smartfon mode on desktop and work using it.

This is already fixed in git-master.

Looks like the dialog overlay does not stop event propagation.

This is a known issue. We have a ticket in Bifrost. Not trivial to fix as it's a bug in fullcalendar library.

Fixed.

Fixed.

There's some inconsistency in Week and Month view behavior and I'm not sure why. In Week view a single click does not select the slot, it opens new event dialog. In Month view a single click will just select the slot. I don't like this inconsistency. The slot selection itself is useless and could be removed, so a single click in Month view would also open the new event dialog (with proper date set). Looks like a bug.

These categories are there for interoperability. They come from iCalendar standard (the CLASS property). The functionality in Kolab is limited to:

1. Additional decoration of private/confidential event in event preview dialog.
2. When a calendar folder annotated as confidential/private exists all incoming invitations marked as such will be stored in these folders (instead of the default calendar) by invitation policy module if enabled.

We do not store the last button state, but I guess it would be possible.

Is the border not enough?

That's what we've had in the old skin. However, this way the menu button location might not be perfect.

This is intentional. We expect user to use next/previous slot buttons or drag-n-drop. The inputs are only to display current selection.

There's actually a config option (calendar_itip_send_option) that allows to change the behavior as requested. Maybe we should consider changing the default setting.

Makes sense, and it was indeed different in the old skin. Agreed.

I confirm the issue and it is specific to KolabNow. Most likely its caused by cyrus murder topology and a delay in creating a folder on a backend server. So, when the page is refreshed the folder does not yet exist, even if the folder creation command didn't result with an error. Does not happen on my local Kolab installation.

Do you have a device that where that modes switching is possible or you're talking about browser developer tools? There are some quirks like that known when you switch modes.

We're using quite an old version of fullcalendar library that does not support touch events. It's supported in more recent versions https://fullcalendar.io/docs/touch.

Existence of these two tabs depends on the calendar permissions (some calendar drivers might not support them). So, it looks like after calendar delete there's a problem with selecting existing calendar. Confirmed.

Fixed in e85ff388293.

Fixed.

I guess we could implement something similar to the mail compose, when you make an action that will make the mail destroyed (the changes since last auto-save) then you're asked if you're sure. However, this will be too much effort. We should just not make the addresses clickable in event editing mode.

The different background indicates today, not the selected day. Indeed selecting a day in the mini-calendar does not do much (until it's a day in another week, then it switches the week view to selected period).

In T4461#66861, @bohlender wrote:

• remove "subscribe/unsubscribe" for personally owned calendars

Makes sense.

Agreed. I left "Search...." for the main search input and changed the other input to "Find calendars...". I unified all tasks' UI this way. Fixed.

List permanently is like removing from list (unsubscribing), but without immediate effect. So, the record will not appear again if you switch tasks (e.g. goto Mail and back to Calendar). Note that removing from list is not the same as deleting the calendar, it's just deactivating (unsubscribing).

Indeed. I guess we could use tag input widget (see notes or tasks) for categories.