Not a problem in Kolab 16.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 5 2019
I guess this has been fixed as the proposed line already exists.
This depends on Cyrus configuration. The way how Kolab uses Cyrus IMAP does not allow for subfolders under INBOX.
No feedback.
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.
What version of roundcubemail-plugins-kolab? These lines with timezone info are irrelevant. Problem is with parsing some objects in calendar folder(s). You'll have to find the faulty object-message in the spool, or delete folder content. Without the faulty object data we'll not be able to help.
Fixed in 91e57e1f7367.
The documentation is outdated. You can find the repo at https://copr.fedorainfracloud.org/coprs/kanarip/phabricator/
Jun 28 2019
Jun 27 2019
Jun 26 2019
... not mentioning the fact that we still need PHP 5.4 support. So, it's complicated.
All other components (iRony, kolab plugins for Roundcube) depend on that version. So, we can't just switch to a new one.
I pushed the the change I proposed above. I consider it fixed. Let me know if I'm wrong.
Jun 25 2019
Could you confirm that this code works for you? I think it should work with SabreDAV 2.1 as well as any newer version.
$is_dir = !empty($props['{DAV:}resourcetype']) && count($props['{DAV:}resourcetype']->getValue()) > 0;
I'm trying to tell you that your patch is not acceptable because it does not work with Kolab's WebDAV server (and maybe others). From the debug you provided I see that it might be a Sabre compat. issue. For me it is different:
Sabre\DAV\Property\ResourceType::__set_state(array( 'resourceType' => array ( 0 => '{DAV:}collection', ), ))
What version of SabreDAV do you have installed?
Jun 24 2019
However, I don't get it. Does that mean that OwnCloud returns set-but-empty DAV:resourcetype for folders? Could you provide sample owncloud response? Or, is commit d1342141be6 working for you?
Proposed solution does not work with Kolab's WebDAV implementation (iRony). However, indeed standard says that files have no contenttype, so I'm going to fix it anyway.
Case 1 is already implemented.
It's part of Kolab 16.
Jun 21 2019
Jun 20 2019
Jun 19 2019
Jun 18 2019
Fixed in be2e3f21541 [roundcubemail master].
Jun 14 2019
Jun 13 2019
It looks good, but I don't really know it does what it looks like it should be doing ;)
Jun 12 2019
Jun 11 2019
This version does not work with Roundcube 1.3.
You're using the outdated fork repo. The official one is here https://git.kolab.org/diffusion/RPK/repository/master/
these versions may require Roundcube from git-master.
Jun 7 2019
Fixed.
Jun 6 2019
Jun 5 2019
Jun 2 2019
Jun 1 2019
Please, be more clear. I don't have owncloud installation. Are you saying that it returns full folders hierarchy event if we ask for "1,noroot"? My understanding of owncloud and other dav servers was that they do (may) not support "infinity", but "1,noroot" should be supported. And this is what the rest of the code expects.
May 31 2019
I'm reopening this as there are more related issues. E.g. the Check Calendar button points to the wrong date.
This was hard to track, but fixed.
No such issue on CentOS with wallace-0.8.11-7.1.el7.kolab_16.
May 30 2019
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.
May 29 2019
Fixed in 668ca02c3f3d8 [roundcubemail master].
Confirmed. If I then try to start wallace, I got:
2019-05-29 11:36:24,741 pykolab.wallace WARNING [10320] Could not bind to socket on port 10026 on bind address localhost 2019-05-29 11:36:24,741 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:25,743 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:26,745 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:27,747 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:28,750 pykolab.wallace WARNING [10320] Could not shut down socket ...
and
# ps ax | grep wallace 3595 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10320 ? Sl 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10321 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10322 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10323 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10324 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab
Fixed on kolabnow.com.
What is the user date and time format? You could also check what are the input arguments to parseDate() in line 169 of libcalendaring.js file. Just add console.log(this.datepicker_settings.dateFormat, date, this.datepicker_settings) a line before.
I didn't check that on Debian 8, but a few notes:
- It's not an issue on Debian 9 indeed.
- Roundcube will not fallback to any other method if it is configured to use pspell.
I think I saw this before, but never had time to work on this. Probably the date is handled as date-time and converted to user timezone, but should not for all-day events.
I confirm. This is for the Kolab skin based on Larry. Looks like it is caused by some style in Larry. The responsive skin has no such issue.