Fixed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 30 2018
Fixed.
Nov 28 2018
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:
- Additional decoration of private/confidential event in event preview dialog.
- 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.
Nov 27 2018
Nov 26 2018
Unfortunately I don't have the permissions to delete or edit that page, even with my admin account. Assigning to @vanmeeuwen.
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.
Nov 25 2018
Nov 23 2018
Is there any action I can take to aid in getting this patch (and others) into Kolab?
Fix a bug in cache handling: Global Resources and Global Address List need distinct caches.
Nov 22 2018
Nov 19 2018
Nov 16 2018
this is related to T4458 (it is not ready for you yet)
-> mockup
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).
-> hallway test
In T4461#66861, @bohlender wrote:
- remove "subscribe/unsubscribe" for personally owned calendars
@machniak feedback?
@machniak feedback?
In T4461#66828, @machniak wrote:Maybe it's indeed too much. Maybe we just need "Add to list" and "Remove from list".
Reducing options is a good idea
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.
Fixed.
Nov 15 2018
@machniak the main reason for this suggestion is consistency.
It is possible to expand the event downward, so users will likely expect that it is also possible to expand it upward too.
That should be doable. I just want to note that I think this is a rare situation. If you already decided that the meeting/event will take one hour, it is more likely that you'll want to keep it one hour even when moved to another slot. I see real life scenarios when that would be handy, but I hear that request for the first time, which means it's not that common case.