(09:06:30) bohlender: petersen: vanmeeuwen: I am in the process of reworking the event editor for elastic. (see https://git.kolab.org/T4845 for screenshots). there are two fields that don't seem to be used by kolab (privacy & priority). In the privacy case, this is actually a usability bug because users could assume that their "private" event is not displayed to others the calendar is shared with. Can we remove these two fields or am I missing a reason to keep them?
(09:08:21) vanmeeuwen: i don't care much for either, but private does have a use-case in the sending back and forth of invitations and the recipient putting it not in a default calendar but instead a calendar marked as private
(09:09:05) vanmeeuwen: so in this case the "private" checkbox would basically indicate "for any attendees that do have a private calendar to have wallace automatically store events in, put it there"
(09:09:30) petersen: How do you mean that they do not get used by Kolab? Those fields exist in Kolab and can be set..
(09:10:37) alec: you can set them, but that's all you can do + the case described above
(09:11:10) petersen: we have had a number of requests for the usecase mentioned above..
(09:12:06) petersen: priority doesn't make much sense to me in a calendar..
(09:12:25) vanmeeuwen: unless we make wallace obey it ;-)
(09:12:52) vanmeeuwen: "lunch, priority 3", "invitation to meeting, priority 1" -> BOOM
(09:13:00) petersen: right
(09:13:20) petersen: perhaps it doesn't make sense to me because we didn't do so yet
(09:14:19) vanmeeuwen: it's wrong in that it is at the sender's discretion
(09:14:25) petersen: with all the above in mind, I would not remove those for now - Bring it to Bern next week - We'll have time to discuss it on Wednesday
(09:15:26) bohlender: alright. thank you for your feedback
(09:15:41) vanmeeuwen: the simpler approach would be to remove the arbitrarily confusing shit out of the way of one's workflow
(09:15:55) vanmeeuwen: which is not to say i've reviewed the tickets / ideas / proposals
(09:16:09) petersen: we will discuss next Wednesday

@machniak I gave roundcube development a try:

I think this is about a known iOS/Safari bug where cursor is still visible even if the textarea/input is out of screen (page scrolled). I don't know if there are workarounds. Need investigation.

This is working out of the box, but requires long-press. After a long press you can move the event. After a long press event also a handle to resize the event appears, so you can also resize the event.

I don't think we can control that with current design. For me scrolling in the dialog is consistent. Problems start when a virtual keyboard appears.

Fixed on kolabnow.com.

I don't see it on current beta.kolabnow.com withiPone SE iOS 12.1.4. Could you re-test and provide screenshot if it's still an issue?

I'm unable to reproduce on current beta.kolabnow.com with Chromim 73.0.3683.86.

Alright. Let's close this as wontfix then

I'm not sure about how common it is, but we have for example an option to save messages into the folder the replied message comes from. And it is good to have visual information on to which folder the message will be saved while composing. There are also users that wanted occassionally to not save the message at all (as draft or after it's sent). That's why the select contains "- don't save -" option. So, there are some usecases.

In T2720#78512, @machniak wrote:

@bohlender, would you make a summary in English for me, or should I just ignore all comments?

@bohlender, would you make a summary in English for me, or should I just ignore all comments?

Please do consider taking this to whatever the appropriate priority actually is, or however else you keep it off my radar until such time there's some meaningful involvement on my part ;-)

It does not work for me. Maybe there's something to switch in fullCalendar settings or some bug. Need to investigate.

this should now be fixed in 3.4.3.

In a broader sense, many such form fields in the webclient require input confirmation by pressing Enter, including those that initially use a "display filter", like the one able to search listed calendars vs. searching the server-side for all possible options. The exception to the rule seems to be auto-complete.

It seems to me this doesn't have the highest of priorities.

I fail to understand how this is not the expected result. When an input field is selected (presumably the keyboard pops up?), then the cursor is supposed to stick to that input field despite any scrolling, no? The cursor only disappears when a click event happens outside the input field?

Fixed in rRPKa86269b6534a [roundcubemail-plugins-kolab master].

I don't think this is a good idea.

@machniak I tried and it looks cluttered. What works is merging reminder and recurrence in one tab.
Would that work for you?

Done in git-master.

@machniak the reminder can get pretty complex and add a lot of clutter. the easy solution was to (re)move it.
I will try another version with a redesigned reminder field.

@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

@machniak This is what I came up with. Would that work for you?

This happens beacausse you do not hhave any Calender selected before. So editing a Calender can not work on a specific Calender, for this reason it opens a new add window.

I would suggest that in the time frame the indication of "select time" is shown, and next to these fields, you still have the option of turning the "all day" button on. This way, it would be the same as creating an event in the weekly view, with the only difference being that the time frame can be selected without a default time given.

I think what is not intuitive is to have to turn the "ganztägig" button off in order to enter a time. There is no obvious way to type in a time without turning the "ganztägig" button off. I would also prefer a "Select" window with the possibility to choose "ganztägig".

@bohlender

@bohlender

I agree with @isabel.pacheco

I am not sure about this. Thisway you could create an event that does not have any start time. My usual Calender always puts 10 o'clock and that too is annoying most of the time. You will have to change it anyway, so why do not change from all day to a specific time?
The only thing I would get would be a separate window opening asking to enter the time!

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).

I have never had that problem.

steps to reproduce? video?

I can't reproduce this