- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 21 2019
@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
Feb 20 2019
Feb 19 2019
Feb 18 2019
Feb 8 2019
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).
Feb 7 2019
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).
Yes.
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 "alice@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.
The dialog should disappear, I expect some javascript error here. Any chance we can see browser error console? Does it happen always or need specific event data?
Feb 6 2019
Feb 5 2019
Feb 1 2019
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.
Jan 31 2019
Jan 30 2019
Fixed in cbd1c1ae47b9.
Fixed in ff9be33f7795.
Fixed.
Jan 28 2019
Aside of "applying search w/o need to press Enter" I don't understand the issue.
The issue is fixed in dev/fullcalendar-upgrade branch. It will be merged soon.
Jan 25 2019
This has been fixed in 834266c469dbc [roundcubemail master].
Fixed in 57e061251ee.
Duplicate of T4665.
These warnings does not look relevant, and the syncroton log looks normal. Could you provide imap_debug log? Do you see more requests from the client in http access/error log? I didn't try WindowsMail, but it looks like it just stopped after synchronizing folders hierarchy.
This has been fixed in 5834133fadb9e. Not yet packaged.
Jan 23 2019
Jan 22 2019
The label is untranslated in German. https://www.transifex.com/kolab/kolab/libcalendaring/. So, someone will have to update localization in Transifex first.
Jan 18 2019
Searching email or events is usually more expensive than e.g. filtering already loaded folders or even contacts. So, it might be not fast enough. It may require some work to make sure it's responsive.
Jan 16 2019
Jan 11 2019
Jan 10 2019
I'm not sure. I guess, we would have to mark the input element as type=email. Need to test if that would not cause some issues.
Jan 9 2019
Sure. I just described current design. These inputs are grayed out which means read-only. This comes from Bootstrap framework. Simplest fix would be to make these fields to not look like inputs, but just text.