Hi Oscar,
I guess you found some interesting issues. Some of them will probably
take longer to solve than for the “bug fix release”, but I’ll see.
(see futher below)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan v. Lieshout escribió:
Hi Oscar,
as I normally only used the forum for the mailinglist and it was out of
order, I didnot answer your mail before.
Now I read that it can take some time before it works again, I will try
the mailinglist to answer your post.
Just some comfortability: this mail from you is out of the thread chain,
so I’d avoid using forum or other tools instead of mail if possible.
yeh, it is actually out of thread, because this is the first mail ever
that I sent to the mailinglist now that I’am forced to use email instead
of the forum (as its not working anymore) 
I’ve just downloaded and tested 0.9.37-ng, so the results below are all
updated testing this version.
I hope of both icalsrv and egwical…
but when I click any .ics
shown in the list using the url icalsrv.php[/user]/list.html, I get this:
PHP Parse error: parse error, unexpected ‘=’, expecting ‘)’ in
…/egroupware/icalsrv/inc/class.virtual_calendar.inc.php on line 142
which I’ve workearound (maybe it’s a php4 issue) by not assigning any
default value to the last parameter “&rwdirtable”, but this leads to
another php error, exactly the same but in
…/egwical/inc/class.icalvcb.inc.php on line 154
Yes these are, as mentioned in the FAQ in the icalsrv documentation typical php4 vs php5 discrepancies.
Just keep this as reminder.
After fixing this one, too, I get “ical stuff”, but with some issues:
- I didn’t realize that, event being https, the links changed to http:
I dont understand what you mean here. As I test the latest version, it works with
both http and https. In a previous version the list.html didnot detect if it was retrieved
via https and thus listed all virtual calendars via a http link. But in the latest version
this was fixed to list them as https urls when the list.html page was accessed this way.
Is this what you are reffering to or is it something else?
Just this. And still turns https into http. The url is kept as https,
but the generated links using list.html they all use http.
Well maybe its because the test that I use to detect if it is ssl or not
doesnot work with your server. It seems, according to various
information sources on the web, that a good --interplatform-- working
test to discern between these is hard too find. I found that a
moderately supported candidate should be my:
isset($_SERVER[‘HTTPS’]) && strtolower($_SERVER[‘HTTPS’]) == ‘on’
test. It works for me (apache 2.5x) and I heard for a few people on the
mailinglist that it worked too. As the forum is not there anymore, I
cannot
see anymore what your server setup was, but if it doesnot support this
test, this could be the cause.
If you have a better alternative/addition, please let me hear of course.
- The real domain isn’t being managed. What I did yesterday was with
just one domain, but using a non default domain is still being
overlooked, even if I append domain=mydomain in the url (to be used with
$_GET[‘domain’], just like when being at the login screen)
Are you sure about this? I tested that the domain as set by the domain=mydomain
parameter is actually correctly used by the session create routine:
$GLOBALS[‘egw’]->session->create($userlogin, …)
Here $userlogin now has the user@domain value.
But I must admit that this is the only thing that I do with the domain, so if anything
else has to be done to make a correct login for a non default domain, please let me know
what and if possible refer to some example code…
I have only a default domain in my current test environment and wont be changing this before
sunday, so I at the moment I cannot test these matters myself.
That’s part of the problem, but I’ll expand it for a better picture:
Ok, I’ll try to follow what you explain…
In a installation with two egw domains (in this case it’s cvs, but I
think it’s exactly the same code than 0.9.37-ng, according to the
diffs),
Thats right there should be no difference between cvs and 0.9.37-ng.
I’m already logged in as my user, but in a domain that is not
the default.
I guess you do this in the browser (not that it is important but for
clarity…), so now you have a session for lets say:
myuser@nondefdomain
Then, without logging out, I enter the
icalsrv.php/oscar/list.html url in the browser, where I’m prompted the
user and password. First, I try “user@domain”, but it’s rejected (I
didn’t check any log to trace the reason better),
Yes, that will always be rejected I believe, only username is “user”,
with the url extended to …/list.html?domain=“domain” could work at the
moment.
so I try just “user”,
and I get the list (and http instead of https in the links).
Oke, if you succeded then it took as value for the domain: "default"
So now you should have --wanted or not ;)-- a session for “user@default”
Then, I
click back in the browser, and the identity has changed to the other
domain.
Hmm I dont know exactly the semantics of clicking back within a browser,
and even less for clicking back (can you do that?) in a real calendar
client,
but nevertheless we can speculate on it…
I think that if there’s an active session, it should be read.
But anyway, I think the switch of domain is a bit ambiguous, because I
miss some things, like calendar itself, so it seems some things are
melted.
Dont understand what you mean by this: is it that after you (possibily
unaware of the fact) authenticated as “user@default”, do you not get the
calendar and infolog information you should get for this login?
I must admit that this logging in for a non default domain is far from
transparent or easy. But dont immediately can come up with an easier
variant: apparently the variant where you can authenticate with
user@domain as username wont work because some part of the http session
mechanism cannot digest the '@ sign, so the php code doesnot even get a
chance to see it all. Though I hope I am wrong with this observation, it
was my first impression of the problem.
If you want, I can provide an account for you to test it yourself.
That is nice offer, but I am afraid that it is of little use if I cannot
read the errorlog. And I suppose thats not a possibility… Else I am
interested
- I think that the charset issue has not been fixed. The default
installation uses iso-8859-1 just to test these issues. Just to be sure
you know the problem, I think all stuff must be returned in utf-8 (by
RFC, according to what I’ve been told by calendar developers),
regardless the used charset, and you have to take care that the incoming
stuff in utf-8 gets converted to the used charset (if necessary, of
course). I think that the general function for this is defined in the
"convert" function in the translation class in phpgwapi, where the
function definition is:
I was aware of this problem, but AFAIK I had this translation ialready activated since version v0.9.30
or so. Certainly in all the “NG” versions. At least for the content of value and parameter fields.
The code that does it you can find in class.eicnvutils line 760 to 770 or so.
Did you actually find a problem with it when testing?
Then please let me know in more detail. I heard from others (Cornelius a.o.) that it worked ok…
Note that this utf-8 translation has nothing todo with the COMMA escaping that I added in the last
release. Maybe that confused you?
I’ve just tested it and definitely it’s NOT 100% solved, but 50% solved.
I’m just testing with with calendar extension from mozilla.org. If I
write in egw an event (with special characters, of course) in egw and
sync with mozilla calendar, I see it ok, but if I edit the same event in
mozilla and publish it, in egw I lose the special characters.
Ok thats a clear problem description that I should be able to reproduce.
Although maybe a bit hard because I never use special characters
willingly. (I know, computers left the stone age, but I started with
fortran that only had uppercase symbols so I learned to live with a
small alphabet 
)
I looked it up in the code: it appears (class.bocalupdate_vevents line
669) that it already does a utf-8 to egw translation for each field
value, via:
$attrval =
$GLOBALS[‘egw’]->translation->convert($attr[‘value’],‘UTF-8’);
But…, it is still not done for parameter values, so did you add the
special characters to a place where it is transported via a iCalendar
parameter?
Maybe you can export a mozilla event calendar to file with some special
characters that go wrong and email it to me?
However, I’m experiencing something strange with tasks. When trying to
sync using icalsrv.php/oscar/default.ics, I get (as popup in the browser):
"Invalid SQL: SELECT main.info_id FROM egw_infolog main WHERE (
(info_owner= OR (CONCAT(’,’,info_responsible,’,’) LIKE ‘%,%’ AND
info_access=‘public’) OR (CONCAT(’,’,info_responsible,’,’) LIKE ‘%,%‘
OR info_status = ‘offer’ AND info_owner IN()) AND (info_access=‘public’
OR info_owner IN ())) AND info_type=‘task’ AND
(CONCAT(’,’,info_responsible,’,’) LIKE ‘%,3,%’ OR info_responsible=‘0’
AND info_owner=3) )
mysql Error: 1064 (You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near ‘OR (CONCAT(’,’,info_responsible,’,’) LIKE ‘%,%’ AND
info_access)
File: …/egroupware/infolog/inc/class.soinfolog.inc.phpLine: 587
Function: soinfolog::search /
boinfolog::search / icalvircal::export_vcal
Hmm very strange… I would say that the search goes wrong, but AFAIC see
there is no info from the published calendar textually involved in the
search. Only your user_id that is already translated into 3, and the id
of the virtual calendar (user) is used. I dont know what the correct
sql syntac ought to be here, but maybe the latter id somehow got not
insert well.
If I could reproduce this with an example calendar file of you, it would seem important to fix.
Did you get this also when you retry it? Lately I also sometimes get
sql errors (maybe only when using a browser, but am not sure…) and it
always appears that when I retry it (refresh the page) they are gone and
it works! One example is when I use as url only …icalsrv.php (so
without anything appended to it)
Quite terrible because this is hard to debug…
and the used charset is surely somewhere in $GLOBALS[‘egw_info’]. Maybe
Ralf or anybody else can give a hint about how to handle this
PS. I will start replacing --if possible in a simple, decent way-- some of the php4 offending constructs
in the coming version so that people with php4 will easier get results.
I start with this in the next version (v0.9.37-ng-2) to come. So if you find more of them (the previous 2
I have noted down already) let me know.
Well, I’d thank you to announce updates at least in this list, that I
think is where developers (and maybe testers) are more comfortable.
Dont know about that. Previous releases I announce here and in users and
the majority of reponses came from users. But, yes, I would say it
certainly belongs here! And response from one is already enough to
convince me
regards
Jan
Regards.
----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://pgp.escomposlinux.org |
----------------------------------------------------------------------|
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
