@bohlender you omitted the Reminder field, you think it should be in the Summary tab? I think it should.
I like it. Especially that you didn't add a new tab, but merged with Attachments (we're limited on mobile). As once Jeroen was interested in decluttering event dialog, he might be interested to take a look. @vanmeeuwen
Tue, Feb 19
Mon, Feb 18
Sun, Feb 17
Sat, Feb 16
Fri, Feb 15
Fri, Feb 8
It would be doable, but not simple because of current searching implementation. However, I have a feeling that we're trying to workaround a browser issue of a single user. This definitely would need more arguments to implement autocompletion for title (or any other input).
Thu, Feb 7
This is controlled by the browser, I don't know what we can do about this other than disabling autocompletion (that should be possible with html attribute).
It's not about compatibility. At least nothing comes to my mind regarding this. However, I'm not so sure about "There is no reason to have a meeting without the person with that you're having the meeting knowing there is a meeting".
Yeah, some clients even display the question dialog separately before you start editing. Another thing to do is to think about decluttering the dialog/form, so it does not display all these inputs initially and the question box is visible. Some UX work will be needed.
I think this is non-issue. You don't consider "email@example.com" also confusing?
Are we talking about functionality from Sharing tab in calendar edit dialog? There's "Edit" (it should be "Edit calendar" really) entry in 3-dots-options menu. I'm not sure we need two distinct entries in the menu for sharing and editing. Would that make sense to rename it to "Edit/Share"? Note that not every folder can be shared.
You mean display autocompletion list when you focus the input without entering anything (yet)? Sounds strange. Also, note that autocompletion does not display names and email separately (until, of course there a person without a name specified).
Thanks. So, it auto-scrolls when you move mouse cursor over the list without clicking anything, right?
I think current behaviour is there to get best performance for most common case. It could be "faked" this way, I guess, but not that easy.
It indeed accepts email only, but there's autocompletion implemented and it works with names too. So, I guess the placeholder should be "Participant name or email" (the same for Resources form, I guess). Still, I'm not sure I like it.
Maybe. That might not be trivial as the view switcher is controlled by fullCalendar library and it does not always produce a http request.
Fixed in 8400bbe36ff [roundcubemail-plugins-kolab master].
No issue in Chrome either. I don't have a Mac. I also don't full understand this: "place cursor at the top of the dropdown menu (at around 16:00), expected result: selected time stays the same". When you click a time on selection list the list should hide and the selected time should be inserted into the input. So I don't know what do you mean.
Maybe @vanmeeuwen would have some ideas.
Well, we could. We'd need to store the deletion request for later in some persistent storage and take it from there after timeout. What about a case when a user deletes the calendar and immediately leaves webmail session? Should he then expect the calendar to be deleted on his iPhone? In other words, we could do this on client side only, no IMAP technology (I know of) to do this server-side.
Undeleting a folder requires administrator rights in IMAP. So, such a feature would have security implications and needs more considerations.
Ah, so by "delete your search" you mean cleanup the input field with keyboard. I get it now. Then this is almost a duplicate of T4872, but I'll not close it to make sure it's taken into account.
This is a bug of KolabNow specifically caused by cyrus murder setup there. I think we have a ticket like this already. I'll close this one as it is really nothing I can do on the webmail side.
This is already fixed. As you can see on beta.kolabnow.com/apps right now a single click works everywhere.
Wed, Feb 6
Tue, Feb 5
Mon, Feb 4
Sun, Feb 3
Fri, Feb 1
Added time input validation in 6285d0cf719.
Actually the summary input has been marked as required, but it didn't work in a dialog. Fixed in e92255929229.
That would mean that opening and closing a dialog on mobile would have to modify browser history. Probably possible, but might be tricky.
Thu, Jan 31
Wed, Jan 30
Fixed in cbd1c1ae47b9.
Fixed in ff9be33f7795.
Tue, Jan 29
Mon, Jan 28
Aside of "applying search w/o need to press Enter" I don't understand the issue.