Correcting the priority from 60/40 to Normal
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 22 2019
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
It doesn't seem like there's any actual errors in reality.
Should be fixed by removing pytz from our repositories.
this should now be fixed in 3.4.3.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This seems like low-priority aesthetics to me more so than an actual problem.
No longer relevant.
No longer relevant.
We do not actively support the database backend driver, so please bear in mind this has a very low priority for us.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
The application can't address having run out of file descriptors.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
This ticket is no longer relevant.
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.
eimap is going the way of the dodo, but I'll comply with your request for at least a license.
Folders should generally not have a trailing space, so this should be fixed at the input / form level.
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?
There is nothing...
I've disabled registration.
In the web client, what does Settings > ActiveSync show, and/or what does it show for the "device" or "application" listed?
This fundamentally flawed version of a build system has needed to be patched again, but this crap should now be resolved.
Thanks for your reply. I've just checked and the issue persist. I've tried with my user and I can confirm I logged first in webmail before adding exchange account.
Mar 21 2019
If only things were that easy. :-/
We have no standard definition for "slow", and you're not telling us anything about the system symptoms. High CPU load? High I/O? Memory consumption? Entropy?
What modifications exist against pykolab?
Wallace on CentOS 7 for kolab 16 uses systemd, not sysvinit, so I don't understand what I'm being told here.