Successful upgrade from 2.2.3 to 2.3.1 but...

[-]

Hi,
I had the same problem.
For me this seams to be a bug in the code.
Check

 /kolab/lib/php/Horde/Kolab/Filter/Incoming.php

    foreach ($this->_recipients as $recipient) {
        if (strpos($recipient, '+')) {
            list($local, $rest) = explode('+', $recipient, 2);
            list($rest, $domain) = explode('@', $recipient, 2);
-->        $real_recipient = $local . '@' . $domain;
        } else {
            $real_recipient = $recipient;
        }
        $dn = $server->uidForIdOrMail($real_recipient);
         if (is_a($dn, 'PEAR_Error')) {
            return $dn;
            }
            if (!$dn) {
            Horde::logMessage(sprintf('User %s does not exist!', 
$real_recipient),
            __FILE__, __LINE__, PEAR_LOG_DEBUG);
            }
            $user = $server->fetch($dn, KOLAB_OBJECT_USER);

I changed it it to

     $real_recipient = $rest . '@' . $domain;

Give it a try.

Hans

________________________________
From: Skip Morse <skipmorse at gmail.com>
To: Kolab-User Mailinglist <kolab-users at kolab.org>
Sent: Fri, May 27, 2011 11:30:43 AM
Subject: Re: Successful upgrade from 2.2.3 to 2.3.1 but...

On Fri, May 27, 2011 at 10:30 AM, Skip Morse <skipmorse at gmail.com> wrote:
> So... this seems like it was pretty straight forward, this was just a
> test run (in a test VM), but after one more practice, I'm thinking it
> will probably take me about 30 minutes (if that) to do the production
> upgrade (not counting the backup first).
>
> Here are my concerns before i can really flip the switch.
>
> First issue:
>
> Part of our usage requires that we are able to have email delivered to
> shared folders.  I've always had to use the workaround(s) found here:
> http://wiki.kolab.org/Shared_folders
>
> Most recently, changing the line in ldapvirtual.cf to: query_filter =
> (&(!(kolabDeleteFlag=*))(|(alias=%s)(mail=%s)))
>
> The above line allows sending to a shared folder, but I didn't see any
> updates on the wiki and it turns out that there's something wrong with
> the 'receiving' to a shared folder.  All mails sent to the shared
> folder are stuck in the postfix queue with a temporary failure, and I
> can't tell from the postfix log why.  Just messages like this:
>
> <info> postfix/pipe[16637]: D747BB1D7A:
> to=<kolab+shared.scheduling at domain.com>, relay=kolabmailboxfilter,
> delay=1.2, delays=0.05/0.06/0/1.1, dsn=4.3.0, status=deferred
> (temporary failure)
>
> It's the same result if I send directly to
> kolab+shared.blah at domain.com or if I send to the alias that's in the
> 'vcard' in the address book entry.  There is one line in the wiki that
> I don't quite understand, so maybe this is my answer if anyone has any
> expansion on what this means:
>
> 04/30/2010 - diegows: You have to give post permission to kolab user
> in the shared folder too.
>
> I do have 'anyone' with the 'post' permissions.  Maybe that is no longer 
>enough?
>
> ** As a note, regular user to user mail seems to work fine
>
> Second issue:
>
> Is the web client limited to only the dynamic view now?  I don't hate
> it, but I like the option.  While testing, I happened to log in as a
> user with an outrages amount of top level folders.  This causes some
> folders to not even be viewable and as far as I can tell, no way to
> get to them.  I also couldn't find any settings in the per-user,
> global options to select which layout, maybe i missed it?
>
> Almost all of our users use Outlook and the Toltec connector, so it
> isn't a huge problem for most.  But I would like to imagine that we'll
> migrate most users to the webclient at some point and this may be a
> deal-breaker...
>
> Thoughts/Advice?
>
> Any help is always appreciated.
>
> Thanks,
> -Skip
>

Not sure if this is the key to figuring out the delivery issue, but
I'm getting this error which seems to be new in:

/kolab/var/kolab-filter/log/filter.log

The message:
May 27 20:01:43 Kolab Filter (pid=19208) [error] [horde] Specify
either the UID or a search result!; Code: 331 [pid 19208 on line 181
of "/kolab/lib/php/Horde/Kolab/Server/Object.php"]

I've looked in Object.php, but I can't really make sense of what needs
to happen.  My guess is that this has something to do with the shared
folder not having a UID like a normal user would have.

I'm going to wait to do anything, but I'm think maybe a possible
workaround would be to edit the ldap data so my shared folder has a
uid?

Okay... while writing the above, i looked into the ldap data for the
shared folder entry, the fist dn line is:
dn: cn=scheduling at domain.com,dc=domain,dc=com

For normal users, I *think* the entry was changed using the
kolab-cn2uid script.  But, this failed to change the shared folders
(I'm just not sure if it should).

Does anyone know if it would cause problems if, after running the
above script, I manually changed the shared folder entries to look
like the user's entries (dn:
uid=scheduling at domain.com,dc=domain,dc=com)?

Maybe a better approach if entries of type "kolabSharedFolder" are not
supposed to have a uid, modify the Object.php to be aware of their
existance?

And back to you... :-)

Thanks,
-Skip

_______________________________________________
Kolab-users mailing list
Kolab-users at kolab.org
https://kolab.org/mailman/listinfo/kolab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20110528/5efb24e5/attachment.html>