This week I am hoping to add a feature to the Calendar importer,
allowing links to addressbook entries to be included, a feature with the
Addressbook and Infolog CSV importers already have.
I expect I can mostly follow the examples from the InfoLog CSV importer,
but I'm stuck on how to translate a couple of lines. One is this one
from the InfoLog CSV importer:
What is the equivalent of "$boinfolog" for the Calender? Is it the
"$cal" variable? Will it also support "$cal->link->link()" in the same
way?
And a second question from the InfoLog importer:
$boinfolog->write($to_write);
What does that line do? While I need to use the same syntax for the
Calendar importer?
I also wanted to report that in some places in the CSV importing code I
see references to "cvs_import", which looks like a typo. Perhaps
"csv_import" was meant instead? If the current spelling is correct, I
think a comment is in order in each location to clarify what's going on
there.
first of all, I recommend not to develop in 1.4, as we soon have 1.6.
Mark Stosberg schrieb:
> Hello,
>
> This week I am hoping to add a feature to the Calendar importer,
> allowing links to addressbook entries to be included, a feature with the
> Addressbook and Infolog CSV importers already have.
>
> I expect I can mostly follow the examples from the InfoLog CSV importer,
> but I'm stuck on how to translate a couple of lines. One is this one
> from the InfoLog CSV importer:
>
> $link_id = $boinfolog->link->link('infolog',$id,$app,$app_id);
>
> What is the equivalent of "$boinfolog" for the Calender? Is it the
> "$cal" variable? Will it also support "$cal->link->link()" in the same
> way?
In trunk you use egw_link::link(...) for all applications.
In 1.4 you have to use:
$GLOBALS['egw']->link->link(...) or $cal->link->link(...) (only in the
calendar/csv_import.php
> And a second question from the InfoLog importer:
>
> $boinfolog->write($to_write);
>
> What does that line do?
It writes an infolog entry to the DB.
> While I need to use the same syntax for the Calendar importer?
The writing is alread in the calendar import, otherwise it would not work:
> I also wanted to report that in some places in the CSV importing code I
> see references to "cvs_import", which looks like a typo. Perhaps
> "csv_import" was meant instead? If the current spelling is correct, I
> think a comment is in order in each location to clarify what's going on
> there.
That's a (consequent) typo, if you change it now, you loose your current
settings.
I implemented just the linking for trunk, while answering your mail (and
looking for the function names).
You can find the modifications (in case you want to backport them to
1.4) in the changelog: www.egroupware.org/changelog (on the next full
hour, as it updates only hourly).
Ralf
--
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0
> Hi Mark,
>
> first of all, I recommend not to develop in 1.4, as we soon have 1.6.
>
> Mark Stosberg schrieb:
> > Hello,
> >
> > This week I am hoping to add a feature to the Calendar importer,
> > allowing links to addressbook entries to be included, a feature with the
> > Addressbook and Infolog CSV importers already have.
> >
> > I expect I can mostly follow the examples from the InfoLog CSV importer,
> > but I'm stuck on how to translate a couple of lines. One is this one
> > from the InfoLog CSV importer:
> >
> > $link_id = $boinfolog->link->link('infolog',$id,$app,$app_id);
> >
> > What is the equivalent of "$boinfolog" for the Calender? Is it the
> > "$cal" variable? Will it also support "$cal->link->link()" in the same
> > way?
>
> In trunk you use egw_link::link(...) for all applications.
>
> In 1.4 you have to use:
> $GLOBALS['egw']->link->link(...) or $cal->link->link(...) (only in the
> calendar/csv_import.php
>
> > And a second question from the InfoLog importer:
> >
> > $boinfolog->write($to_write);
> >
> > What does that line do?
>
> It writes an infolog entry to the DB.
>
> > While I need to use the same syntax for the Calendar importer?
>
> The writing is alread in the calendar import, otherwise it would not work:
>
> 1.4: $cal->bo->update(...)
> trunk: $cal->update(...)
>
> > I also wanted to report that in some places in the CSV importing code I
> > see references to "cvs_import", which looks like a typo. Perhaps
> > "csv_import" was meant instead? If the current spelling is correct, I
> > think a comment is in order in each location to clarify what's going on
> > there.
>
> That's a (consequent) typo, if you change it now, you loose your current
> settings.
>
> I implemented just the linking for trunk, while answering your mail (and
> looking for the function names).
>
> You can find the modifications (in case you want to backport them to
> 1.4) in the changelog: www.egroupware.org/changelog (on the next full
> hour, as it updates only hourly).
> I implemented just the linking for trunk, while answering your mail (and
> looking for the function names).
Great!
You might have also see this in the bug tracker, but there's another easy bug to fix while you
are in there. The custom field names aren't showing up. Here's the patch I put in the bug tracker:
185c187
< foreach ($custom_fields as $name => $data)
---
> foreach ($custom_fields['customfields'] as $name => $data)
####
It looks like the bug persists in the 1.6 branch, based on your diff.
while implementing the links to addressbook in calendar, I also noticed
that wrong customfields stuff and fixed it, with a new static method
from trunk:
>> I implemented just the linking for trunk, while answering your mail (and
>> looking for the function names).
>
> Great!
>
> You might have also see this in the bug tracker, but there's another easy bug to fix while you
> are in there. The custom field names aren't showing up. Here's the patch I put in the bug tracker:
>
> 185c187
> < foreach ($custom_fields as $name => $data)
> ---
>> foreach ($custom_fields['customfields'] as $name => $data)
>
> ####
>
> It looks like the bug persists in the 1.6 branch, based on your diff.
>
> Mark
>
>
>
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________
> eGroupWare-developers mailing list
> eGroupWare-developers@... > https://lists.sourceforge.net/lists/listinfo/egroupware-developers
--
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0
Here's my patch (attached) for the 1.4 branch for custom-field importing for calendars.
However, no links are appearing, although I can see from debugging output that
it appears that they should be. Perhaps it matters that nearly all of my imported data
are "updates", because of their Unique IDs?
Thanks again!
Mark
[calendar_linking_14.diff] --- csv_import.php.bak 2007-11-29 11:32:46.000000000 -0500
+++ csv_import.php 2008-07-08 09:50:39.000000000 -0400
@@ -148,6 +148,7 @@
case 'continue':
case 'download':
$GLOBALS['egw']->preferences->read_repository();
+ # XXX: Typo here to say "cvs" instead of "csv" ?
$defaults = $GLOBALS['egw_info']['user']['preferences']['calendar']['cvs_import'];
if (!is_array($defaults))
{
@@ -176,13 +177,16 @@
'modified' => 'Modification date',
'non_blocking' => '0=Event blocks time, 1=Event creates no conflicts',
'uid' => 'Unique Id, allows multiple import to update identical entries',
+ 'link_1' => '1. link: appname:appid the entry should be linked to, eg.: addressbook:123',
+ 'link_2' => '2. link: appname:appid the entry should be linked to, eg.: addressbook:123',
+ 'link_3' => '3. link: appname:appid the entry should be linked to, eg.: addressbook:123',
// 'recur_type'=> 'Type of recuring event',
);
$config =& CreateObject('phpgwapi.config','calendar');
$custom_fields = $config->read_repository();
unset($config);
//echo "custom-fields=<pre>".print_r($custom_fields,True)."</pre>";
- foreach ($custom_fields as $name => $data)
+ foreach ($custom_fields['customfields'] as $name => $data)
{
$cal_names['#'.$name] = $data['label'].': Custom field ('.$data['type'].')';
}
@@ -303,6 +307,7 @@
}
$GLOBALS['egw']->preferences->read_repository();
+ # XXX: "cvs" and not "csv" is a typo here?
$GLOBALS['egw']->preferences->add('calendar','cvs_import',$defaults);
$GLOBALS['egw']->preferences->save_repository(True);
$log .= "\t\t".'<td align="center">'.($cal_id ? $action." cal_id=$cal_id" : 'Error '.$action)."</td>\n\t</tr>\n";
}
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________
eGroupWare-developers mailing list
eGroupWare-developers@... https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Re: Seeking mentoring for adding addressbook linking to Calendar CSV importer
On Tue, 8 Jul 2008 09:56:25 -0400
Mark Stosberg <mark@...> wrote:
> Here's my patch (attached) for the 1.4 branch for custom-field importing for calendars.
>
> However, no links are appearing, although I can see from debugging output
> that it appears that they should be. Perhaps it matters that nearly all of my
> imported data are "updates", because of their Unique IDs?
I've narrowed down the bug I'm having with 1.4.
The final import report includes a column that says "link_1" and includes
correct values like "addressbook:123" in it.
However, if I look at the value of 'link_1' just before the linking happens, it's empty!:
