6.0.0-git
2019-03-20

[#12505] Free/busy URL is not found on re-open of events
Summary Free/busy URL is not found on re-open of events
Queue Kronolith
Queue Version 4.1.2
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester lst_hoe02 (at) kwsoft (dot) de
Created 2013-07-26 (2063 days ago)
Due
Updated 2013-12-17 (1919 days ago)
Assigned 2013-11-21 (1945 days ago)
Resolved 2013-11-23 (1943 days ago)
Milestone
Patch No

History
2013-12-17 11:40:36 Git Commit Comment #18 Reply to this comment
Changes have been made in Git (master):

commit b12876eabf8f952f2ef05a382daa31fc76411423
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Sat Nov 23 13:15:31 2013 -0500

     Don't normalize the email addresses toLower.

     We don't do this anywhere else, technically address parts are case
     sensitive, and this can cause freebusy information to be unavailable
     when querying systems that ARE case sensitive, like Turba.

     See Bug: 12505

  kronolith/lib/Api.php   |    7 +++----
  kronolith/lib/Event.php |    3 +--
  2 files changed, 4 insertions(+), 6 deletions(-)

http://git.horde.org/horde-git/-/commit/b12876eabf8f952f2ef05a382daa31fc76411423
2013-11-23 18:18:40 Michael Rubinsky Comment #16
Assigned to Michael Rubinsky
State ⇒ Resolved
Reply to this comment
Kronolith 4.2.0
2013-11-21 20:50:02 Michael Rubinsky Comment #15 Reply to this comment
First sorry for sounding harsh in the last comment.

It would of course be a win to not lowercase the mailaddress and 
afterwards searching case sensitive, yes. IMMHO we should try as 
hard as possible to find a useable FB-URL, because they are rare 
anyway and even using the wrong one would not be  a disaster as the 
FB-URL is only a hint for planing anyway.
Well, the problem with that is that the user might not know it's the 
wrong FB info.  Anyway, your patch won't necessarily solve the issue 
in the first place since even a non-strict search on a sql database 
that is case sensitive will fail. As far as I know, the strictness 
only controls requiring a full equals match vs a wildcard match.
But this needs fixing in Javascript, no?
Not sure if we are normalizing in the js or php off hand.
2013-11-21 20:32:38 lst_hoe02 (at) kwsoft (dot) de Comment #14 Reply to this comment
First sorry for sounding harsh in the last comment.

It would of course be a win to not lowercase the mailaddress and 
afterwards searching case sensitive, yes. IMMHO we should try as hard 
as possible to find a useable FB-URL, because they are rare anyway and 
even using the wrong one would not be  a disaster as the FB-URL is 
only a hint for planing anyway.

But this needs fixing in Javascript, no?
2013-11-21 18:03:22 Michael Rubinsky Comment #13
State ⇒ Feedback
Priority ⇒ 1. Low
Reply to this comment
If anything, we should not be normalizing the email addresses to lower 
case when saving them in the Kronolith event since we are not doing 
that in Turba.
2013-11-21 18:00:46 Michael Rubinsky Comment #12 Reply to this comment
In addition, removing the strict match could cause email addresses to 
be included that were not meant to be. For instance, it's unlikely, 
but mike@example.co would also match mike@example.com. Or 
mike@example.ne would match mike@example.net.


2013-11-21 17:48:12 lst_hoe02 (at) kwsoft (dot) de Comment #11 Reply to this comment
Strictly speaking it is possible that the local-part is case 
sensitive, the domain part never was. It is also fact that no one sane 
in mind ever distinguished between local-part and Local-part. If we go 
that road please also "fix" the initial search to not find the address 
at all. With this the FB URLs would be finally useless at all.

This RFC part is historically from using login usernames as local-part 
which might be case sensitive like in Unix or not like in Windows. 
Today there is no real relation between local-part and system accounts 
anyway.


2013-11-21 17:40:13 Michael Rubinsky Comment #10
State ⇒ Not A Bug
Reply to this comment
The patch is technically wrong because according to RFC5321, an email 
address may very well be case sensitive.
2013-11-21 17:21:13 lst_hoe02 (at) kwsoft (dot) de Comment #9 Reply to this comment
Any one from the developers is able to comment on this?

Thanks
2013-10-16 10:17:29 lst_hoe02 (at) kwsoft (dot) de Comment #8 Reply to this comment
So this would be the patch to make the search case insensitive, but as 
said i don't what other fuzzyness the nonstrict search will result in.

--- kronolith/lib/FreeBusy.php        2013-10-02 16:36:27.000000000 +0200
+++ kronolith/lib/FreeBusy.patch.php        2013-10-16 12:13:50.000000000 +0200
@@ -253,7 +253,7 @@

          try {
              $result = $GLOBALS['registry']->call('contacts/getField',
-                                                 array($email, 
'freebusyUrl', $sources, true, true));
+                                                 array($email, 
'freebusyUrl', $sources, false, true));
          } catch (Horde_Exception $e) {
              return false;
          }


2013-10-10 09:39:13 Jan Schneider State ⇒ Unconfirmed
 
2013-10-02 14:35:18 lst_hoe02 (at) kwsoft (dot) de Comment #7 Reply to this comment
in kronolith/lib/FreeBusy.php the Turba getField call is used to fetch 
the FB-URL. At this call (around line 254) the parameter strict is set 
to "true" which lead to case sensitive search which breaks FB-URL 
finding if the email field is used with mixed case like 
Vname.Nname@domain. Is it possible to use strict = false or does this 
break other things. What kind of "strictness" is enforced with this 
parameter??
2013-09-30 14:57:27 lst_hoe02 (at) kwsoft (dot) de Comment #6 Reply to this comment
A lowercase search Problem. We had e-mail address like 
"Vname@domain.tld" in the address book. On creating the event this is 
stored as "vname@domain.tld" and with obviously case-sensitive match 
on reopen the address is not found.

Testcase:
Create a contact entry with e-mail like this "Vname@domain.tld" and a 
valid FB-URL. Add this to a new event -> FB Info is shown. Reopen the 
event and a FB-URL error is shown and the FB Info is not present any 
more.

Is this fixable in the Javascript code?
2013-08-16 15:24:09 Jan Schneider State ⇒ No Feedback
 
2013-07-30 15:21:43 Michael Rubinsky Comment #5 Reply to this comment
Creating the F/B display is done in Javascript, no? So i have to 
look in js/kronolith.js for the difference between creating and 
updating the event??
Yes, the display is created in javascript, but the freebusy data is 
generated in PHP from the getFreeBusy Ajax call 
(Kronolith_Ajax_Application_Handler::getFreeBusy()). You can look 
there, and also use Firebug or similar tool to see what the Ajax 
request is actually sending/receiving.
2013-07-29 15:01:15 lst_hoe02 (at) kwsoft (dot) de Comment #4 Reply to this comment
Creating the F/B display is done in Javascript, no? So i have to look 
in js/kronolith.js for the difference between creating and updating 
the event??
2013-07-26 16:02:45 lst_hoe02 (at) kwsoft (dot) de Comment #3 Reply to this comment
Cannot reproduce.
It looks like the addressbook used for f/b URL search must have 
"use_shares=false", with the personal addressbook it works. So create 
a second backend in turba with "use_shares=false" to test. The 
question is why there is a difference between creating and opening the 
event regarding this.
2013-07-26 13:26:33 Michael Rubinsky Comment #2
State ⇒ Feedback
Reply to this comment
Cannot reproduce.
2013-07-26 08:11:35 lst_hoe02 (at) kwsoft (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Free/busy URL is not found on re-open of events
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
Creating an event with attendees which have a free/busy URL in the 
adressbook set for kronolith works as expected and show the free/busy 
information. After saving the event and then reopen it, one always get 
the warning "no free/busy URL for <e-mail> found" for all attendees. 
So it looks like the search for f/b URL is different for creating and 
reopen??

Saved Queries