From discuss@opengroupware.org Wed Mar 14 18:55:23 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Wed, 14 Mar 2007 19:55:23 +0100
Subject: [OGo-Discuss] ogo task reminder
Message-ID: <20070314185524.12A0A3AEDF@l00-bugdead-prods.de>
Hi,
developer@opengroupware.org wrote:
>
> As an aside I'd like to discuss@ the job notification feature. If you
> could post your explanation of the problem/deficiency and the logic of
> your proposed solution over on discuss@ it would be appreciated.
>
ok, lets rock. Above Adam refers to the following ogo enhancement:
.http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1167
Enh: If a job is due, but not finished, the user should be notified.
the patch I added to the report, does not fully what the name says.
the skyjobnotify tool started out as a copying the functionality of
skyaptnotify.
this enables the user to define a job specific reminder time before the due
date,
so that he will receive an e-mail notification, if the reminder date has
reached.
the tool skyjobnotify should be run from a cron job as its friend skyaptnotify.
- the skyjobnotify tool is configured with the Defaults just like skyaptnotify:
skyjobnotify = {
JobNotifyBeVerbose = NO;
JobNotifyCheckPrefix = 600;
JobNotifyDefaultTimeZone = MET;
JobNotifyFromAddress = "ogo@mydomain";
JobNotifySendmailPath = "/usr/sbin/sendmail";
JobNotifySendmailToExternal = NO;
JobNotifySendpageEnabled = NO;
JobNotifySentResourcesFile = "/var/log/opengroupware.org/ogo.log";
JobNotifySkyrixPassword = MyPassword;
JobNotifySkyrixUser = ogoadmin;
};
- notification_time column in the job table (as compared to the date_x table for
appointments)
- same logic behind the values stored in notification_time as for appointments,
minutes before the end_date of the job which are later compared to the
end_date of the
fetched jobs.
- skyjobnotify mostly relies on commands, runCommand:@"job::get-job-executants,
runCommand:@"person::get-extattrs, job::set, job::get-skyjobnotify-jobs, ...
- job::get-skyjobnotify-jobs just asks the database for all jobs that are not
archived or
done and have a notificationTime > 0 set
qualifier = [qualifier initWithEntity:[self destinationEntity]
qualifierFormat:
@"(%A <> '%@') AND "
@"(%A <> '%@') AND "
@"(%A > 0)",
@"jobStatus", LSJobArchived,
@"jobStatus", LSJobDone,
@"notificationTime", nil];
- skyjobnotify only checks for the mails (email, email1, email2) of the executer
of the job,
and sends the notification out to these addresses
- the e-mail reminder looks like the following:
Task Notification
title: testreminder
owner: ogouser
start-date: 2007-03-11 01:00 (MET)
end-date: 2007-03-13 01:00 (MET)
status:
sensitivity: 1
priority: 1
actual work: 0
total work: 0
- skyjobnotify leaves a hard coded log entry in the jobs history "reminder sent"
- In the webui, a default reminder preference can be defined by the user in the
jobs
preferences page
- when creating a job, the user can choose the reminder time from a popup, same
as for
appointment reminders
- when a reminder is set, and not yet sent out, then it shows up in the webui
most likely there are bugs in it, but as far as i tested for now, it works,
despite still
some quirks in the webui, where the reminder time is not shown correctly.
maybe improvements:
- reminder could be sent to the creator, if he is not one of the executors
- improved template for the notification, e.g. including the url link to the
task in ogo.
- maybe more...
comments are welcome.
kind regards
Sebastian
From discuss@opengroupware.org Thu Mar 15 11:21:54 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Thu, 15 Mar 2007 07:21:54 -0400
Subject: [OGo-Discuss] oliver's fancy dock code
Message-ID: <1173957714.5030.11.camel@aleph.whitemice.org>
Looking at http://docs.opengroupware.org/Members/olivier/NewDock/
There must be more two this than just the three patches:
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1732
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1734
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1735
- although I understand those are the only "code" parts.
Are the theme files available anywhere? There isn't an obvious link on
the plone page.
From discuss@opengroupware.org Thu Mar 15 13:25:11 2007
From: discuss@opengroupware.org (Olivier Hallot)
Date: Thu, 15 Mar 2007 10:25:11 -0300
Subject: [OGo-Discuss] oliver's fancy dock code
In-Reply-To: <1173957714.5030.11.camel@aleph.whitemice.org>
References: <1173957714.5030.11.camel@aleph.whitemice.org>
Message-ID: <45F94937.2070303@scinergy.com.br>
Adam,
On the bottom of the page mentioned, there is a link to get the files.
The theme is in two files, the webresources and the templates (both are
tar.gz).
Thank's for taking care of it.
Olivier
Adam Tauno Williams escreveu:
> Looking at http://docs.opengroupware.org/Members/olivier/NewDock/
>
> There must be more two this than just the three patches:
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1732
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1734
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1735
> - although I understand those are the only "code" parts.
>
> Are the theme files available anywhere? There isn't an obvious link on
> the plone page.
>
--
Olivier Hallot
Scinergy Consulting
Tel (021) 8822-8812
Rio de Janeiro, Brasil
http://www.scinergy.com.br
From discuss@opengroupware.org Thu Mar 15 14:02:57 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Thu, 15 Mar 2007 10:02:57 -0400
Subject: [OGo-Discuss] oliver's fancy dock code
In-Reply-To: <45F94937.2070303@scinergy.com.br>
References: <1173957714.5030.11.camel@aleph.whitemice.org>
<45F94937.2070303@scinergy.com.br>
Message-ID: <1173967377.4394.19.camel@aleph.whitemice.org>
--=-trglLgnbx/Cm9XuKJuCL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> On the bottom of the page mentioned, there is a link to get the files.
> The theme is in two files, the webresources and the templates (both are
> tar.gz).
Doh! "Get the theme files"
> Thank's for taking care of it.
I haven't done anything yet. :)
> > Looking at http://docs.opengroupware.org/Members/olivier/NewDock/
> > There must be more two this than just the three patches:
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1732
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1734
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1735
> > - although I understand those are the only "code" parts.
> > Are the theme files available anywhere? There isn't an obvious link on
> > the plone page.
--=-trglLgnbx/Cm9XuKJuCL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBF+VIRLRePpNle04MRAjLPAJ41892WFugpWmnCRHB2x+OwDBdQugCcD/w9
FZFp0AGsOMcJVzo7e5lp4QA=
=+Zc5
-----END PGP SIGNATURE-----
--=-trglLgnbx/Cm9XuKJuCL--
From discuss@opengroupware.org Thu Mar 15 14:20:22 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Thu, 15 Mar 2007 10:20:22 -0400
Subject: [OGo-Discuss] ogo task reminder
In-Reply-To: <20070314185524.12A0A3AEDF@l00-bugdead-prods.de>
References: <20070314185524.12A0A3AEDF@l00-bugdead-prods.de>
Message-ID: <1173968422.4394.37.camel@aleph.whitemice.org>
--=-n1zUIqIi5f8YLax00Jib
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> > As an aside I'd like to discuss@ the job notification feature. If you
> > could post your explanation of the problem/deficiency and the logic of
> > your proposed solution over on discuss@ it would be appreciated.
> ok, lets rock. Above Adam refers to the following ogo enhancement:
> .http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1167
> Enh: If a job is due, but not finished, the user should be notified.
> the patch I added to the report, does not fully what the name says.
> the skyjobnotify tool started out as a copying the functionality of
> skyaptnotify.
> this enables the user to define a job specific reminder time before the d=
ue
> date, so that he will receive an e-mail notification, if the reminder dat=
e has
> reached.
Which is awesome, I've wanted this for a long time. Currently I run an
SQL to get a nice list of nearly due or overdue jobs.
> the tool skyjobnotify should be run from a cron job as its friend skyaptn=
otify.=20
> - the skyjobnotify tool is configured with the Defaults just like skyaptn=
otify:
> skyjobnotify =3D {
> JobNotifyBeVerbose =3D NO;
> JobNotifyCheckPrefix =3D 600;
> JobNotifyDefaultTimeZone =3D MET;
> JobNotifyFromAddress =3D "ogo@mydomain";
> JobNotifySendmailPath =3D "/usr/sbin/sendmail";
> JobNotifySendmailToExternal =3D NO;
> JobNotifySendpageEnabled =3D NO;
> JobNotifySentResourcesFile =3D "/var/log/opengroupware.org/ogo.lo=
g";
> JobNotifySkyrixPassword =3D MyPassword;
> JobNotifySkyrixUser =3D ogoadmin;
> };
> - notification_time column in the job table (as compared to the date_x ta=
ble for
> appointments)
Any schema changes are going to need the blessing of the PTBs; makes
upgrading/updating, packaging, etc... more complicated.
> - same logic behind the values stored in notification_time as for appoint=
ments,=20
> minutes before the end_date of the job which are later compared to the
> end_date of the=20
> fetched jobs.
> - skyjobnotify mostly relies on commands, runCommand:@"job::get-job-execu=
tants,=20
> runCommand:@"person::get-extattrs, job::set, job::get-skyjobnotify-jobs=
, ...
> - job::get-skyjobnotify-jobs just asks the database for all jobs that are=
not
> archived or=20
> done and have a notificationTime > 0 set
> qualifier =3D [qualifier initWithEntity:[self destinationEntity]
> qualifierFormat:
> @"(%A <> '%@') AND "
> @"(%A <> '%@') AND "
> @"(%A > 0)",
> @"jobStatus", LSJobArchived,
> @"jobStatus", LSJobDone,
> @"notificationTime", nil];
> - skyjobnotify only checks for the mails (email, email1, email2) of the e=
xecuter
> of the job, and sends the notification out to these addresses
Makes sense to me. I'd image than the adding of the logic command and
the adding of the tool should be separate patches. Maybe "skyjobnotify"
should be "ogojobnotify".
> - the e-mail reminder looks like the following:
> Task Notification
> title: testreminder
> owner: ogouser
> start-date: 2007-03-11 01:00 (MET)
> end-date: 2007-03-13 01:00 (MET)
> status: =20
> sensitivity: 1
> priority: 1
> actual work: 0
> total work: 0
> - skyjobnotify leaves a hard coded log entry in the jobs history "reminde=
r sent"
Is this derived from a template or hard-coded?
> - In the webui, a default reminder preference can be defined by the user =
in the
> jobs preferences page
What is the name of the default created?
> - when creating a job, the user can choose the reminder time from a popup=
, same
> as for appointment reminders
> - when a reminder is set, and not yet sent out, then it shows up in the w=
ebui
> most likely there are bugs in it, but as far as i tested for now, it work=
s,
> despite still some quirks in the webui, where the reminder time is not sh=
own correctly.
> maybe improvements:
> - reminder could be sent to the creator, if he is not one of the executor=
s
Hmmm, I don't know. Doesn't seem very useful. I *assume* the creator
has an interest and keeps a better eye on things than the executant. :)
> - improved template for the notification, e.g. including the url link to =
the
> task in ogo.
I think including the link is imperative.
> - maybe more...
What happens if the executant is a team?
--=-n1zUIqIi5f8YLax00Jib
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBF+VYmLRePpNle04MRAhk/AJ0YyZSMOPMSdkc0jcG7B7VoBaOVUQCePECO
uvug+CEfYnIZIMdZEep5tE4=
=yQYT
-----END PGP SIGNATURE-----
--=-n1zUIqIi5f8YLax00Jib--
From discuss@opengroupware.org Thu Mar 15 15:11:56 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Thu, 15 Mar 2007 16:11:56 +0100
Subject: [OGo-Discuss] ogo task reminder
Message-ID: <20070315151157.0FEAE3B0D0@l00-bugdead-prods.de>
Hi,
discuss@opengroupware.org wrote:
> > > As an aside I'd like to discuss@ the job notification feature. If you
> > > could post your explanation of the problem/deficiency and the logic of
> > > your proposed solution over on discuss@ it would be appreciated.
> > ok, lets rock. Above Adam refers to the following ogo enhancement:
> > .http://bugzilla.opengroupware.org/bugzilla/show bug.cgi?id=1167
> > Enh: If a job is due, but not finished, the user should be notified.
> > the patch I added to the report, does not fully what the name says.
> > the skyjobnotify tool started out as a copying the functionality of
> > skyaptnotify.
> > this enables the user to define a job specific reminder time before the
due
> > date, so that he will receive an e-mail notification, if the reminder
date has
> > reached.
>
> Which is awesome, I've wanted this for a long time. Currently I run an
> SQL to get a nice list of nearly due or overdue jobs.
>
> > the tool skyjobnotify should be run from a cron job as its friend
skyaptnotify.
> > - the skyjobnotify tool is configured with the Defaults just like
skyaptnotify:
> > skyjobnotify = {
> > JobNotifyBeVerbose = NO;
> > JobNotifyCheckPrefix = 600;
> > JobNotifyDefaultTimeZone = MET;
> > JobNotifyFromAddress = "ogo@mydomain";
> > JobNotifySendmailPath = "/usr/sbin/sendmail";
> > JobNotifySendmailToExternal = NO;
> > JobNotifySendpageEnabled = NO;
> > JobNotifySentResourcesFile
= "/var/log/opengroupware.org/ogo.log";
> > JobNotifySkyrixPassword = MyPassword;
> > JobNotifySkyrixUser = ogoadmin;
> > };
> > - notification time column in the job table (as compared to the date x
table for
> > appointments)
>
> Any schema changes are going to need the blessing of the PTBs; makes
> upgrading/updating, packaging, etc... more complicated.
I know, and I thought about that, but I decided, just for consistency, it
would make sense to copy the logic how things work from appointment, would
be the better idea. As there were no extendedJobAttributes... which I could
have used, as I started. At least I was not aware of the patch in bugzilla.
>
> > - same logic behind the values stored in notification time as for
appointments,
> > minutes before the end date of the job which are later compared to the
> > end date of the
> > fetched jobs.
> > - skyjobnotify mostly relies on commands,
runCommand:@"job::get-job-executants,
> > runCommand:@"person::get-extattrs, job::set,
job::get-skyjobnotify-jobs, ...
> > - job::get-skyjobnotify-jobs just asks the database for all jobs that
are not
> > archived or
> > done and have a notificationTime > 0 set
> > qualifier = [qualifier initWithEntity:[self destinationEntity]
> > qualifierFormat:
> > @"(%A <> '%@') AND "
> > @"(%A <> '%@') AND "
> > @"(%A > 0)",
> > @"jobStatus", LSJobArchived,
> > @"jobStatus", LSJobDone,
> > @"notificationTime", nil];
> > - skyjobnotify only checks for the mails (email, email1, email2) of the
executer
> > of the job, and sends the notification out to these addresses
>
> Makes sense to me. I'd image than the adding of the logic command and
> the adding of the tool should be separate patches. Maybe "skyjobnotify"
> should be "ogojobnotify".
yes, I just named it for consistency, maybe renaming skyaptnotify too?
>
> > - the e-mail reminder looks like the following:
> > Task Notification
> > title: testreminder
> > owner: ogouser
> > start-date: 2007-03-11 01:00 (MET)
> > end-date: 2007-03-13 01:00 (MET)
> > status:
> > sensitivity: 1
> > priority: 1
> > actual work: 0
> > total work: 0
> > - skyjobnotify leaves a hard coded log entry in the jobs
history "reminder sent"
>
> Is this derived from a template or hard-coded?
This is copied from skyaptnotify, so should work the same way, with a
template definable via a Default.
>
> > - In the webui, a default reminder preference can be defined by the user
in the
> > jobs preferences page
>
> What is the name of the default created?
>
> > - when creating a job, the user can choose the reminder time from a
popup, same
> > as for appointment reminders
> > - when a reminder is set, and not yet sent out, then it shows up in the
webui
> > most likely there are bugs in it, but as far as i tested for now, it
works,
> > despite still some quirks in the webui, where the reminder time is not
shown correctly.
> > maybe improvements:
> > - reminder could be sent to the creator, if he is not one of the
executors
>
> Hmmm, I don't know. Doesn't seem very useful. I *assume* the creator
> has an interest and keeps a better eye on things than the executant. :)
>
> > - improved template for the notification, e.g. including the url link to
the
> > task in ogo.
>
> I think including the link is imperative.
well I need to find out, how to generate the link, and make it available in
the e-mail...
>
> > - maybe more...
>
> What happens if the executant is a team?
I have not tested, but I think the same will happen, as when a team is an
appointment participant. I only copied it from skyaptnotify.
kind regards
Sebastian
From discuss@opengroupware.org Fri Mar 16 05:18:27 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Fri, 16 Mar 2007 06:18:27 +0100
Subject: [OGo-Discuss] ogo task reminder
Message-ID: <20070316051828.658A03B1E3@l00-bugdead-prods.de>
Hi,
> >
> > Makes sense to me. I'd image than the adding of the logic command and
> > the adding of the tool should be separate patches. Maybe "skyjobnotify"
> > should be "ogojobnotify".
> yes, I just named it for consistency, maybe renaming skyaptnotify too?
>
I splitted up the patch, and renamed any sky... to ogo..., here is the part
of the command ogojobnotify:
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1848
A cleaned up patch for the taskreminder itself will follow...
kind regards
Sebastian
From discuss@opengroupware.org Fri Mar 16 17:16:34 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Fri, 16 Mar 2007 13:16:34 -0400
Subject: [OGo-Discuss] ogo task reminder
In-Reply-To: <20070315151157.0FEAE3B0D0@l00-bugdead-prods.de>
References: <20070315151157.0FEAE3B0D0@l00-bugdead-prods.de>
Message-ID: <1174065394.4921.29.camel@aleph.whitemice.org>
--=-kt5MB7GDuwkFB0oXB7sa
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> >> - notification time column in the job table (as compared to the date x=
=20
> >> table for appointments
> > Any schema changes are going to need the blessing of the PTBs; makes
> > upgrading/updating, packaging, etc... more complicated.
> I know, and I thought about that, but I decided, just for consistency, it=
=20
> would make sense to copy the logic how things work from appointment, woul=
d=20
I agree that this is the ideal solution (at least IMO)
> be the better idea. As there were no extendedJobAttributes... which I cou=
ld=20
> have used, as I started. At least I was not aware of the patch in bugzill=
a.
I just wonder if, for the sake of getting something sooner, if a simpler
solution wouldn't work.=20
In my understanding tasks have a due *DATE* and not a start *TIME* like
an appointment. Would it be sufficient to simply store a "reminder"
property on the task, and to process the tasks for the day? Early in
the day an e-mail could be sent to user(s) concerning what tasks they
have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).
Or make the property an int, number of days 1, 2, 3, or 4. Then you'd
only need to scan the tasks due in the next 4 days - even at large sites
that shouldn't be more than a few hundred.
In the morning the user could have an e-mail "Your due tasks" or some
such.
I do something like this with SQL, but with no OGo/WebUI integration,
you just get the message for all your tasks. Just making that optional
would be a huge improvement.
> > Makes sense to me. I'd image than the adding of the logic command and
> > the adding of the tool should be separate patches. Maybe "skyjobnotify=
"
> > should be "ogojobnotify".
> yes, I just named it for consistency, maybe renaming skyaptnotify too?
That would break people's existing crontabs, etc... so probably not.
> > > - the e-mail reminder looks like the following:
> > > Task Notification
> > > title: testreminder
> > > owner: ogouser
> > > start-date: 2007-03-11 01:00 (MET)
> > > end-date: 2007-03-13 01:00 (MET)
> > > status: =20
> > > sensitivity: 1
> > > priority: 1
> > > actual work: 0
> > > total work: 0
> > > - skyjobnotify leaves a hard coded log entry in the jobs=20
> history "reminder sent"
> > Is this derived from a template or hard-coded?
> This is copied from skyaptnotify, so should work the same way, with a=20
> template definable via a Default.
Cool.
> > > - In the webui, a default reminder preference can be defined by the u=
ser=20
> > >in the jobs preferences page
> > What is the name of the default created?
> > > - when creating a job, the user can choose the reminder time from a=20
> > > popup, same
> > > as for appointment reminders
> > > - when a reminder is set, and not yet sent out, then it shows up in t=
he=20
> > > webui most likely there are bugs in it, but as far as i tested for no=
w, it=20
> > > works, despite still some quirks in the webui, where the reminder tim=
e is not=20
> > > shown correctly. maybe improvements:
> > > - reminder could be sent to the creator, if he is not one of the=20
> > > executors
> > Hmmm, I don't know. Doesn't seem very useful. I *assume* the creator
> > has an interest and keeps a better eye on things than the executant. :
> > > - improved template for the notification, e.g. including the url link=
to=20
> the
> > > task in ogo.
> > I think including the link is imperative.
> well I need to find out, how to generate the link, and make it available =
in=20
> the e-mail...
> > > - maybe more...
> > What happens if the executant is a team?
> I have not tested, but I think the same will happen, as when a team is an=
=20
> appointment participant. I only copied it from skyaptnotify.
--=-kt5MB7GDuwkFB0oXB7sa
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBF+tDyLRePpNle04MRAteOAJwPiGitiGOF1Kfb78WUJB6d2/v+ZQCdEvjG
t815Yn/AhZytxwQw8z4IjSs=
=s7Tu
-----END PGP SIGNATURE-----
--=-kt5MB7GDuwkFB0oXB7sa--
From discuss@opengroupware.org Fri Mar 16 17:50:50 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Fri, 16 Mar 2007 13:50:50 -0400
Subject: [OGo-Discuss] ogo task reminder
In-Reply-To: <1174065394.4921.29.camel@aleph.whitemice.org>
References: <20070315151157.0FEAE3B0D0@l00-bugdead-prods.de>
<1174065394.4921.29.camel@aleph.whitemice.org>
Message-ID: <1174067450.4921.33.camel@aleph.whitemice.org>
--=-CiMgLvlievSdrTNZdEW1
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> > >> - notification time column in the job table (as compared to the date=
x=20
> > >> table for appointments
> > > Any schema changes are going to need the blessing of the PTBs; makes
> > > upgrading/updating, packaging, etc... more complicated.
> > I know, and I thought about that, but I decided, just for consistency, =
it=20
> > would make sense to copy the logic how things work from appointment, wo=
uld=20
> I agree that this is the ideal solution (at least IMO)
> > be the better idea. As there were no extendedJobAttributes... which I c=
ould=20
> > have used, as I started. At least I was not aware of the patch in bugzi=
lla.
> I just wonder if, for the sake of getting something sooner, if a simpler
> solution wouldn't work.=20
> In my understanding tasks have a due *DATE* and not a start *TIME* like
> an appointment. Would it be sufficient to simply store a "reminder"
> property on the task, and to process the tasks for the day? Early in
> the day an e-mail could be sent to user(s) concerning what tasks they
> have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).
> Or make the property an int, number of days 1, 2, 3, or 4. Then you'd
> only need to scan the tasks due in the next 4 days - even at large sites
> that shouldn't be more than a few hundred.
> In the morning the user could have an e-mail "Your due tasks" or some
> such.
> I do something like this with SQL, but with no OGo/WebUI integration,
> you just get the message for all your tasks. Just making that optional
> would be a huge improvement.
FYI, the query I use is:
WHERE "job_status" NOT IN ( '25_done', '30_archived', '02_rejected' )=20
AND is_control_job IS NULL=20
AND start_date < 'tomorrow'
AND end_date < 'tomorrow'::DATE + INTERVAL '4 days'
--=-CiMgLvlievSdrTNZdEW1
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBF+tj6LRePpNle04MRAgF6AJ4wOKxWAAdtRRO+F6tB+d+w95N/JgCdECvh
V3QK6UnCpSh7gsXglWTGigo=
=fMaj
-----END PGP SIGNATURE-----
--=-CiMgLvlievSdrTNZdEW1--
From discuss@opengroupware.org Sun Mar 18 09:01:39 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Sun, 18 Mar 2007 10:01:39 +0100
Subject: [OGo-Discuss] ogo task reminder
Message-ID: <20070318090139.D65593B4FE@l00-bugdead-prods.de>
discuss@opengroupware.org wrote:
> > > >> - notification time column in the job table (as compared to the
date x
> > > >> table for appointments
> > > > Any schema changes are going to need the blessing of the PTBs; makes
> > > > upgrading/updating, packaging, etc... more complicated.
> > > I know, and I thought about that, but I decided, just for consistency,
it
> > > would make sense to copy the logic how things work from appointment,
would
> > I agree that this is the ideal solution (at least IMO)
> > > be the better idea. As there were no extendedJobAttributes... which I
could
> > > have used, as I started. At least I was not aware of the patch in
bugzilla.
> > I just wonder if, for the sake of getting something sooner, if a simpler
> > solution wouldn't work.
> > In my understanding tasks have a due *DATE* and not a start *TIME* like
> > an appointment. Would it be sufficient to simply store a "reminder"
> > property on the task, and to process the tasks for the day? Early in
> > the day an e-mail could be sent to user(s) concerning what tasks they
> > have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).
> > Or make the property an int, number of days 1, 2, 3, or 4. Then you'd
> > only need to scan the tasks due in the next 4 days - even at large sites
> > that shouldn't be more than a few hundred.
> > In the morning the user could have an e-mail "Your due tasks" or some
> > such.
> > I do something like this with SQL, but with no OGo/WebUI integration,
> > you just get the message for all your tasks. Just making that optional
> > would be a huge improvement.
>
> FYI, the query I use is:
> WHERE "job status" NOT IN ( '25 done', '30 archived', '02 rejected' )
> AND is control job IS NULL
> AND start date < 'tomorrow'
> AND end date < 'tomorrow'::DATE + INTERVAL '4 days'
adding the 02_rejected makes sense to me, but I do not know what the
control_job is for?
Sebastian
From discuss@opengroupware.org Sun Mar 18 09:33:39 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Sun, 18 Mar 2007 10:33:39 +0100
Subject: [OGo-Discuss] ogo task reminder
Message-ID: <20070318093339.95A453B507@l00-bugdead-prods.de>
Hi,
>
> I just wonder if, for the sake of getting something sooner, if a simpler
> solution wouldn't work.
>
> In my understanding tasks have a due *DATE* and not a start *TIME* like
> an appointment. Would it be sufficient to simply store a "reminder"
> property on the task, and to process the tasks for the day? Early in
I prefer it not to change the way how it works right now, in my eyes it is
the cleanest way to go.
> the day an e-mail could be sent to user(s) concerning what tasks they
> have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).
ah, yes, I see now, I removed the labels from the webui to select reminder
values smaller than a day ;)
>
> Or make the property an int, number of days 1, 2, 3, or 4. Then you'd
> only need to scan the tasks due in the next 4 days - even at large sites
> that shouldn't be more than a few hundred.
the database field is an int, but stores the reminder value in minutes.
>
> In the morning the user could have an e-mail "Your due tasks" or some
> such.
>
yes, good idea, maybe the user should be able to configure whether he wants
to have an e-mail for each due job, or a summary of all in one.
> I do something like this with SQL, but with no OGo/WebUI integration,
> you just get the message for all your tasks. Just making that optional
> would be a huge improvement.
>
> > > Makes sense to me. I'd image than the adding of the logic command and
> > > the adding of the tool should be separate patches.
Maybe "skyjobnotify"
> > > should be "ogojobnotify".
renamed it, and splitted the patch into the logic, and the ogojobnotify tool
including the webui patches.
> That would break people's existing crontabs, etc... so probably not.
yeah, makes sense.
> > > > - In the webui, a default reminder preference can be defined by the
user
> > > >in the jobs preferences page
> > > What is the name of the default created?
job_defnotifytime
> > > > - when creating a job, the user can choose the reminder time from a
> > > > popup, same
> > > > as for appointment reminders
> > > > - when a reminder is set, and not yet sent out, then it shows up in
the
> > > > webui most likely there are bugs in it, but as far as i tested for
now, it
> > > > works, despite still some quirks in the webui, where the reminder
time is not
> > > > shown correctly. maybe improvements:
> > > > - reminder could be sent to the creator, if he is not one of the
> > > > executors
> > > Hmmm, I don't know. Doesn't seem very useful. I *assume* the creator
> > > has an interest and keeps a better eye on things than the executant. :
;)
> > > > - improved template for the notification, e.g. including the url
link to
> > the
> > > > task in ogo.
> > > I think including the link is imperative.
> > well I need to find out, how to generate the link, and make it available
in
skyaptnotify does not include a link to the appointment too, so it's not a
big deal in not having a link included yet. When I get an idea on how to add
it, then I think it might be easy to add it there too.
> > the e-mail...
> > > > - maybe more...
> > > What happens if the executant is a team?
> > I have not tested, but I think the same will happen, as when a team is
an
> > appointment participant. I only copied it from skyaptnotify.
I checked again, and found out that teams as executants would not work at
all. Now I changed it, to send to the team email, if set, or to resolve all
team members, and send individual email to each team member.
kind regards
Sebastian
>
From discuss@opengroupware.org Mon Mar 19 13:26:25 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Mon, 19 Mar 2007 09:26:25 -0400
Subject: [OGo-Discuss] ogo task reminder
In-Reply-To: <20070318090139.D65593B4FE@l00-bugdead-prods.de>
References: <20070318090139.D65593B4FE@l00-bugdead-prods.de>
Message-ID: <1174310785.4400.15.camel@aleph.whitemice.org>
--=-sTbzQZEHB8WR254kewbL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> > FYI, the query I use is:
> > WHERE "job status" NOT IN ( '25 done', '30 archived', '02 rejected' )=20
> > AND is control job IS NULL=20
> > AND start date < 'tomorrow'
> > AND end date < 'tomorrow'::DATE + INTERVAL '4 days'
> adding the 02_rejected makes sense to me, but I do not know what the=20
> control_job is for?
Nobody does. :) And they don't seem to occur anymore. But if you have a
system that has been around for awhile (ours has been running since
2003?) you are likely to have some floating around in your database.
--=-sTbzQZEHB8WR254kewbL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBF/o+BLRePpNle04MRAuNCAJ9Gq5Gx1p4MOgTqBGETsfyvpMhnfQCdE16g
hV/zSo5ekb4rtM+UXEMKk3k=
=lA8Q
-----END PGP SIGNATURE-----
--=-sTbzQZEHB8WR254kewbL--
From discuss@opengroupware.org Mon Mar 19 15:39:56 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Mon, 19 Mar 2007 16:39:56 +0100
Subject: [OGo-Discuss] ogo task reminder
Message-ID: <20070319153957.518C03B2EA@l00-bugdead-prods.de>
Hi,
discuss@opengroupware.org wrote:
> > > FYI, the query I use is:
> > > WHERE "job status" NOT IN ( '25 done', '30 archived', '02 rejected' )
> > > AND is control job IS NULL
> > > AND start date < 'tomorrow'
> > > AND end date < 'tomorrow'::DATE + INTERVAL '4 days'
> > adding the 02 rejected makes sense to me, but I do not know what the
> > control job is for?
>
> Nobody does. :) And they don't seem to occur anymore. But if you have a
hehe ;)
> system that has been around for awhile (ours has been running since
> 2003?) you are likely to have some floating around in your database.
no, mine are not running since then.
Nevertheless, this reminds me in updating the database query of the logic
command.
kind regards
Sebastian
PS: I uploaded a patch for task notifications to be sent out via
jabber/xmpp, and have it working 95% for appointments too, so expect a patch
enhancement for skyaptnotify this evening ;)
From discuss@opengroupware.org Mon Mar 19 18:07:33 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Mon, 19 Mar 2007 14:07:33 -0400
Subject: [OGo-Discuss] ogo task reminder
In-Reply-To: <20070318093339.95A453B507@l00-bugdead-prods.de>
References: <20070318093339.95A453B507@l00-bugdead-prods.de>
Message-ID: <1174327653.4406.8.camel@aleph.whitemice.org>
--=-r+DCDg9VcaKGOW+0MHl2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> > I just wonder if, for the sake of getting something sooner, if a simple=
r
> > solution wouldn't work.=20
> > In my understanding tasks have a due *DATE* and not a start *TIME* like
> > an appointment. Would it be sufficient to simply store a "reminder"
> > property on the task, and to process the tasks for the day? Early in
> I prefer it not to change the way how it works right now, in my eyes it i=
s=20
> the cleanest way to go.=20
Okay.
> > the day an e-mail could be sent to user(s) concerning what tasks they
> > have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).
> ah, yes, I see now, I removed the labels from the webui to select reminde=
r=20
> values smaller than a day ;)=20
> > Or make the property an int, number of days 1, 2, 3, or 4. Then you'd
> > only need to scan the tasks due in the next 4 days - even at large site=
s
> > that shouldn't be more than a few hundred.
> the database field is an int, but stores the reminder value in minutes.
Right, just like the date_x reminder field.
> > In the morning the user could have an e-mail "Your due tasks" or some
> > such.=20
> yes, good idea, maybe the user should be able to configure whether he wan=
ts=20
> to have an e-mail for each due job, or a summary of all in one.
> > I do something like this with SQL, but with no OGo/WebUI integration,
> > you just get the message for all your tasks. Just making that optional
> > would be a huge improvement.
> > > > Makes sense to me. I'd image than the adding of the logic command =
and
> > > > the adding of the tool should be separate patches. =20
> Maybe "skyjobnotify"
> > > > should be "ogojobnotify".
> renamed it, and splitted the patch into the logic, and the ogojobnotify t=
ool=20
> including the webui patches.=20
> > That would break people's existing crontabs, etc... so probably not.
> yeah, makes sense.
> >>>>- In the webui, a default reminder preference can be defined by the u=
ser
>> > > >in the jobs preferences page
> > > > What is the name of the default created?
> job_defnotifytime
Ok
> > > > > - maybe more...
> > > > What happens if the executant is a team?
> > > I have not tested, but I think the same will happen, as when a team i=
s=20
> > > an=20
> > > appointment participant. I only copied it from skyaptnotify.
> I checked again, and found out that teams as executants would not work at=
=20
> all. Now I changed it, to send to the team email, if set, or to resolve a=
ll=20
> team members, and send individual email to each team member.
Ok, seems reasonable.
--=-r+DCDg9VcaKGOW+0MHl2
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBF/tFkLRePpNle04MRAmQUAJ4hjLWuSlethi4wPtqgvHGHSTB8zwCfWeM0
Lh1sYSprAAZj1D2CQMAj88Y=
=AJk1
-----END PGP SIGNATURE-----
--=-r+DCDg9VcaKGOW+0MHl2--
From discuss@opengroupware.org Sat Mar 24 17:30:05 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Sat, 24 Mar 2007 13:30:05 -0400
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
Message-ID: <1174757405.4459.15.camel@aleph.whitemice.org>
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1852
This seems useful, and overdue; it has come up on the mailing list
before although I can't seem to find the thread. It also seems related
to Bug#1274
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1274
Outlook provides an IM address field and this is stored in the
im_address field of the person table. But it doesn't seem to provide
any way to specify what kind of IM service is being used; so I like the
Bug#1852 solution better.
Question #1) Is there any kind of policy/philosophy with regard to
adding new types of extended attributes?
Question #2) If the Bug#1852 solution is used perhaps we should consider
created an extended attribute type of each of the *major* IM service
types so a corresponding URL can be generated. XMPP, OSCAR (AIM/ICQ),
MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and 25?
Can each of these services be referenced via URL?
As mentioned in the bug, XMPP URLs are described in
http://www.ietf.org/rfc/rfc4622.txt
From discuss@opengroupware.org Sat Mar 24 17:32:59 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Sat, 24 Mar 2007 13:32:59 -0400
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types
in OGo
In-Reply-To: <1174757405.4459.15.camel@aleph.whitemice.org>
References: <1174757405.4459.15.camel@aleph.whitemice.org>
Message-ID: <1174757579.4459.16.camel@aleph.whitemice.org>
> Question #2) If the Bug#1852 solution is used perhaps we should consider
> created an extended attribute type of each of the *major* IM service
> types so a corresponding URL can be generated. XMPP, OSCAR (AIM/ICQ),
> MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and 25?
> Can each of these services be referenced via URL?
According to wikipedia AIM users can be addressed via URL like:
Send Message
From discuss@opengroupware.org Sat Mar 24 18:49:18 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Sat, 24 Mar 2007 19:49:18 +0100
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field typesin OGo
Message-ID: <20070324184918.823E33D1EB@l00-bugdead-prods.de>
discuss@opengroupware.org wrote:
> > Question #2) If the Bug#1852 solution is used perhaps we should consider
> > created an extended attribute type of each of the *major* IM service
> > types so a corresponding URL can be generated. XMPP, OSCAR (AIM/ICQ),
> > MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and 25?
> > Can each of these services be referenced via URL?
>
> According to wikipedia AIM users can be addressed via URL like:
> Send Message
>
If it is the way it shall go, as I submitted the patch, I can say it would
be easy to add url types for other kinds of instant messaging types.
But in the end, wouldn't it be more flexible to add a Default like
OGoExtendedUrlAttributesMap = (
{ type = email; urlpattern = "mailto:%@"; },
{ type = xmpp; urlpattern = "xmpp:%@"; },
{ type = aim; urlpattern = "aim:goim=screenname=%@"; },
{ type = url; urlpattern = "%@"; },
);
make at least the types url and email mandatory, as they are used already.
and use this in the link generation method. I think that would be easy to
implement.
kind regards
Sebastian
From discuss@opengroupware.org Sun Mar 25 10:01:00 2007
From: discuss@opengroupware.org (Helge Hess)
Date: Sun, 25 Mar 2007 11:01:00 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
In-Reply-To: <1174757405.4459.15.camel@aleph.whitemice.org>
References: <1174757405.4459.15.camel@aleph.whitemice.org>
Message-ID:
On Mar 24, 2007, at 18:30, Adam Tauno Williams wrote:
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1852
>
> This seems useful, and overdue; it has come up on the mailing list
> before although I can't seem to find the thread. It also seems
> related
> to Bug#1274
>
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1274
>
> Outlook provides an IM address field and this is stored in the
> im_address field of the person table. But it doesn't seem to provide
> any way to specify what kind of IM service is being used; so I
> like the
> Bug#1852 solution better.
Hm, yes. As mentioned IMHO an IM field is more like a phone number,
though thats not typed further either. The UI would need to check the
string contents to decide what to render.
But I don't mind ;-)
> Question #1) Is there any kind of policy/philosophy with regard to
> adding new types of extended attributes?
In general extattrs are bad because they slow down the system
(different relation in the DB, lots of joins, assemble/dissably in
the app etc).
Eg email1 should have been company.email from the beginning (I think
it was added later on).
Now the questions was on "new types". Adding new types of course
doesn't hurt, only people using more of them does ;-)
What I always wondered is whether we are going to drop the
'company_value' and use 'obj_property' like other objects. But I
suppose thats not going to happen in the OGo 5.x line given thats it
is a larger change.
> Question #2) If the Bug#1852 solution is used perhaps we should
> consider
> created an extended attribute type of each of the *major* IM service
> types so a corresponding URL can be generated. XMPP, OSCAR (AIM/ICQ),
> MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and
> 25?
Good question. Can't we just have one IM type which stores the IM
service URI. Like: aim:helje5?
Of course the component/element which shows the value must parse this
for display. And the editor might need to support the user.
Its a bit more difficult to implement, but sounds like the better
option to me.
20 would mean: URL which points to a chat identity (in every other
way it would be a regular URL field anyways? [do we have a URL
type?? ;-)])
> Can each of these services be referenced via URL?
Most likely, yes.
Greets,
Helge
--
Helge Hess
http://www.helgehess.eu/
From discuss@opengroupware.org Sun Mar 25 11:28:09 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Sun, 25 Mar 2007 12:28:09 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
Message-ID: <20070325102809.E39983D254@l00-bugdead-prods.de>
Hi,
discuss@opengroupware.org wrote:
> On Mar 24, 2007, at 18:30, Adam Tauno Williams wrote:
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1852
> >
> > This seems useful, and overdue; it has come up on the mailing list
> > before although I can't seem to find the thread. It also seems
> > related
> > to Bug#1274
> >
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1274
> >
> > Outlook provides an IM address field and this is stored in the
> > im_address field of the person table. But it doesn't seem to provide
> > any way to specify what kind of IM service is being used; so I
> > like the
> > Bug#1852 solution better.
>
> Hm, yes. As mentioned IMHO an IM field is more like a phone number,
> though thats not typed further either. The UI would need to check the
> string contents to decide what to render.
> But I don't mind ;-)
good ;)
> > Question #1) Is there any kind of policy/philosophy with regard to
> > adding new types of extended attributes?
>
> In general extattrs are bad because they slow down the system
> (different relation in the DB, lots of joins, assemble/dissably in
> the app etc).
> Eg email1 should have been company.email from the beginning (I think
> it was added later on).
>
> Now the questions was on "new types". Adding new types of course
> doesn't hurt, only people using more of them does ;-)
I started with adding an xmpp: url link, but now I think it would be better
to add sth. more generic than an xmpp link, just add,
The target attribute is used to decide whether to open the link in a new
window or in the current window. For type 4 it defaults to _new, and for the
rest of the types it defaults to _self.
The value stored in e.g. jabberid SkyPublicExtendedPersonAttributes of a
person is used together with the corresponding urlpatterns from the
OGoExtendedUrlAttributesMap Default.
Sebastian
>
> What I always wondered is whether we are going to drop the
> 'company_value' and use 'obj_property' like other objects. But I
> suppose thats not going to happen in the OGo 5.x line given thats it
> is a larger change.
>
>
> > Question #2) If the Bug#1852 solution is used perhaps we should
> > consider
> > created an extended attribute type of each of the *major* IM service
> > types so a corresponding URL can be generated. XMPP, OSCAR (AIM/ICQ),
> > MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and
> > 25?
>
> Good question. Can't we just have one IM type which stores the IM
> service URI. Like: aim:helje5?
>
> Of course the component/element which shows the value must parse this
> for display. And the editor might need to support the user.
> Its a bit more difficult to implement, but sounds like the better
> option to me.
>
> 20 would mean: URL which points to a chat identity (in every other
> way it would be a regular URL field anyways? [do we have a URL
> type?? ;-)])
so I changed the patch to be able to define arbitrary link types via
OGoExtendedUrlAttributesMap Default, for example:
OGoExtendedUrlAttributesMap = (
{
type = 3;
urlpattern = "mailto:%@";
},
{
type = 4;
urlpattern = "%@";
},
{
type = 20;
urlpattern = "xmpp:%@";
},
{
type = 21;
urlpattern = "fish://%@";
},
{
type = 22;
urlpattern = "imaps://%@";
}
);
SkyPublicExtendedPersonAttributes = (
{
key = jabberid;
target = "_self";
type = 20;
},
{
key = anotherurl;
target = "_new";
type = 4;
}
)
the ordinary url type is of type 4 (or has an attribute href) and email is
type 3,
I changed SkyObjectField.m to consider everything above 19 as a special link
type, defined in OGoExtendedUrlAttributesMap, together with a definition of
email and url type.
So this is not yet working for objects using LSWObjectViewer.m, should I add
the same there too? I am not sure whether it is really needed there.
kind regards
Sebastian
From discuss@opengroupware.org Sun Mar 25 11:52:05 2007
From: discuss@opengroupware.org (Helge Hess)
Date: Sun, 25 Mar 2007 12:52:05 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
In-Reply-To: <20070325102809.E39983D254@l00-bugdead-prods.de>
References: <20070325102809.E39983D254@l00-bugdead-prods.de>
Message-ID:
On Mar 25, 2007, at 12:28, Sebastian Reitenbach wrote:
>> 20 would mean: URL which points to a chat identity (in every other
>> way it would be a regular URL field anyways? [do we have a URL
>> type?? ;-)])
>
> so I changed the patch to be able to define arbitrary link types via
> OGoExtendedUrlAttributesMap Default, for example:
>
> OGoExtendedUrlAttributesMap = (
> {
> type = 3;
> urlpattern = "mailto:%@";
> },
> {
> type = 4;
> urlpattern = "%@";
> },
> {
> type = 20;
> urlpattern = "xmpp:%@";
> },
> {
> type = 21;
> urlpattern = "fish://%@";
> },
> {
> type = 22;
> urlpattern = "imaps://%@";
> }
> );
>
>
> SkyPublicExtendedPersonAttributes = (
> {
> key = jabberid;
> target = "_self";
> type = 20;
> },
No, I don't see why we need that many different type codes. Eg the
imaps and fish pattern are useless because the value still needs to
be structure.
A new type only makes sense when the semantic information would be
useful. In all other cases its the task of the UI to process URLs in
a better way.
Wrt to URL patterns, those should be but in the attribute
configuration! Eg:
{
key = jabberid;
target = "_self";
type = 20;
urlpattern = "xmpp:%@";
},
and
{
key = aimid;
target = "_self";
type = 20;
urlpattern = "aim:%@";
},
'20' would just mean its an IM address (having an own type for IM
might make sense, though I'm not entirely convinced of that either
since a generic URL UI can easily detect that a URL is a chat one).
Though I also dislike the urlpattern in this case. The database
should store the full URL, not just the value the user entered. Maybe
'defaultUrlScheme' might make sense (the editor would check whether
the value entered by the user has a scheme and if not, would add the
default scheme).
Thinking about it, for the specific case of IM addresses we should
really use the Outlook field in the way Microsoft uses it. Its sounds
kinda stupid to reinvent the wheel here (how long before people ask
about having IM addresses in Outlook/Evolution ...)
Hm, all that doesn't look very appealing to me. The patches are not
very dangerous and are great fast hacks, but IMHO the issue is not
thought out well enough (and I won't have the time to do it right now).
So feel free to apply them, but I reserve the right to drop support
for that in future versions of OGo ;-)
Thanks,
Helge
--
Helge Hess
http://www.helgehess.eu/
From discuss@opengroupware.org Sun Mar 25 13:54:49 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Sun, 25 Mar 2007 14:54:49 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
Message-ID: <20070325125449.789BD3D276@l00-bugdead-prods.de>
Hi,
>
> No, I don't see why we need that many different type codes. Eg the
> imaps and fish pattern are useless because the value still needs to
> be structure.
Fields from type url (type = 4) are somewhere else handled specially in the
webui, there is somewhere else always sth. like this added:
https://:443/OpenGroupware.woa/wo/4C874C870146066A04/ftp://ftp.de.openbsd.org
and clicking it, will result in an "Not Found" error.
So url fields only seem to work with http: and https: urls.
>
> A new type only makes sense when the semantic information would be
> useful. In all other cases its the task of the UI to process URLs in
> a better way.
>
>
> Wrt to URL patterns, those should be but in the attribute
> configuration! Eg:
> {
> key = jabberid;
> target = "_self";
> type = 20;
> urlpattern = "xmpp:%@";
> },
> and
> {
> key = aimid;
> target = "_self";
> type = 20;
> urlpattern = "aim:%@";
> },
>
yes, if i see this, this would make more sense for me too.
> '20' would just mean its an IM address (having an own type for IM
> might make sense, though I'm not entirely convinced of that either
> since a generic URL UI can easily detect that a URL is a chat one).
as mentioned above, the url field is handled somehow special. I can define a
ftp link with the method above, but just entering ftp://ftphost into the url
field does not work.
>
> Though I also dislike the urlpattern in this case. The database
> should store the full URL, not just the value the user entered. Maybe
> 'defaultUrlScheme' might make sense (the editor would check whether
> the value entered by the user has a scheme and if not, would add the
> default scheme).
well, it could be handled like this, should be easy.
>
> Thinking about it, for the specific case of IM addresses we should
> really use the Outlook field in the way Microsoft uses it. Its sounds
> kinda stupid to reinvent the wheel here (how long before people ask
> about having IM addresses in Outlook/Evolution ...)
but I see only one im_address field in the company table, how is Outlook
using it? Would it be possible to store an arbitrary amount of arbitrary IM
accounts that way?
>
>
> Hm, all that doesn't look very appealing to me. The patches are not
> very dangerous and are great fast hacks, but IMHO the issue is not
> thought out well enough (and I won't have the time to do it right now).
well, they are hacked up fast ;) but I think I'll drop the
OGoExtendedUrlAttributesMap Default in favour of your suggested solution.
> So feel free to apply them, but I reserve the right to drop support
> for that in future versions of OGo ;-)
>
kind regards
Sebastian
From discuss@opengroupware.org Sun Mar 25 14:02:30 2007
From: discuss@opengroupware.org (Helge Hess)
Date: Sun, 25 Mar 2007 15:02:30 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
In-Reply-To: <20070325125449.789BD3D276@l00-bugdead-prods.de>
References: <20070325125449.789BD3D276@l00-bugdead-prods.de>
Message-ID: <56A82A67-4DAC-4904-A77C-13A1F331F37A@opengroupware.org>
On Mar 25, 2007, at 14:54, Sebastian Reitenbach wrote:
> Fields from type url (type = 4) are somewhere else handled
> specially in the
> webui, there is somewhere else always sth. like this added:
> https://:443/OpenGroupware.woa/wo/4C874C870146066A04/ftp://
> ftp.de.openbsd.org
> and clicking it, will result in an "Not Found" error.
> So url fields only seem to work with http: and https: urls.
Report a bug / fix it. No reason why this shouldn't work. Obviously
the URL parser in use is b0rked.
>> Thinking about it, for the specific case of IM addresses we should
>> really use the Outlook field in the way Microsoft uses it. Its sounds
>> kinda stupid to reinvent the wheel here (how long before people ask
>> about having IM addresses in Outlook/Evolution ...)
> but I see only one im_address field in the company table, how is
> Outlook
> using it? Would it be possible to store an arbitrary amount of
> arbitrary IM
> accounts that way?
Don't know, someone would need to check the exact behaviour.
Greets,
Helge
--
Helge Hess
http://www.helgehess.eu/
From discuss@opengroupware.org Sun Mar 25 15:06:16 2007
From: discuss@opengroupware.org (Sebastian Reitenbach)
Date: Sun, 25 Mar 2007 16:06:16 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
Message-ID: <20070325140616.58F483D254@l00-bugdead-prods.de>
Hi,
discuss@opengroupware.org wrote:
> On Mar 25, 2007, at 14:54, Sebastian Reitenbach wrote:
> > Fields from type url (type = 4) are somewhere else handled
> > specially in the
> > webui, there is somewhere else always sth. like this added:
> > https://:443/OpenGroupware.woa/wo/4C874C870146066A04/ftp://
> > ftp.de.openbsd.org
> > and clicking it, will result in an "Not Found" error.
> > So url fields only seem to work with http: and https: urls.
>
> Report a bug / fix it. No reason why this shouldn't work. Obviously
> the URL parser in use is b0rked.
I'll do. I just updated Bug 1852, to allow arbitrary links to be defined as
you suggested. These fields have to be of type = 20, and have to be defined
like this:
{
defaultUrlScheme = "xmpp:";
key = jabberid;
target = "_self";
type = 20;
},
{
defaultUrlScheme = "aim:";
key = aimid;
target = "_self";
type = 20;
},
{
defaultUrlScheme = "ftp://";
key = ftpurl;
target = "_new";
type = 20;
},
{
defaultUrlScheme = "fish://";
key = fishurl;
target = "_new";
type = 20;
},
which at least makes other than http:/https: urls working. If the url fields
is supposed to handle any kind of protocol:// then the type 20 fields are
only useful for such special links like IM links.
kind regards
Sebastian
From discuss@opengroupware.org Sun Mar 25 17:02:46 2007
From: discuss@opengroupware.org (Adam Tauno Williams)
Date: Sun, 25 Mar 2007 12:02:46 -0400
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types
in OGo
In-Reply-To: <20070325125449.789BD3D276@l00-bugdead-prods.de>
References: <20070325125449.789BD3D276@l00-bugdead-prods.de>
Message-ID: <1174838566.4771.2.camel@aleph.whitemice.org>
> > Thinking about it, for the specific case of IM addresses we should
> > really use the Outlook field in the way Microsoft uses it. Its sounds
> > kinda stupid to reinvent the wheel here (how long before people ask
> > about having IM addresses in Outlook/Evolution ...)
> but I see only one im_address field in the company table, how is Outlook
> using it? Would it be possible to store an arbitrary amount of arbitrary IM
> accounts that way?
Agree, as I noted at the top of the thread there is Bug#1274 which talks
specifically about the support of the Outlook IM field.
I don't have access to a ZideLook box at the moment, but I'll check what
Outlook is stored in there when I get a chance. I *suspect* it assumes
their messaging service or is just plain text, but that is just an
assumption.
What to do in respect to supporting the Outlook field vs. other IM
methods, depends on what Outlook is doing. :)
From discuss@opengroupware.org Sun Mar 25 17:14:55 2007
From: discuss@opengroupware.org (Helge Hess)
Date: Sun, 25 Mar 2007 18:14:55 +0200
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo
In-Reply-To: <1174838566.4771.2.camel@aleph.whitemice.org>
References: <20070325125449.789BD3D276@l00-bugdead-prods.de> <1174838566.4771.2.camel@aleph.whitemice.org>
Message-ID:
On Mar 25, 2007, at 18:02, Adam Tauno Williams wrote:
>> Would it be possible to store an arbitrary amount of arbitrary IM
>> accounts that way?
BTW: it wouldn't be the goal to store arbitrary amounts of IM
accounts. The large majority of people (contacts/accounts) have
exactly one IM account they actively use.
So the goal would be to store that one efficiently and correctly. If
we add additional accounts as extra fields, that should be OK. But
there is little point in not using the existing primary field (if
possible).
Thanks,
Helge
--
Helge Hess
http://www.helgehess.eu/
From discuss@opengroupware.org Sun Mar 25 17:18:04 2007
From: discuss@opengroupware.org (Adam Williams)
Date: Sun, 25 Mar 2007 12:18:04 -0400
Subject: [OGo-Discuss] Bug 1852: support creation of xmpp: field types
in OGo
In-Reply-To:
References: <1174757405.4459.15.camel@aleph.whitemice.org>
Message-ID: <1174839484.8709.20.camel@ws01.whitemice.org>
On Sun, 2007-03-25 at 11:01 +0200, Helge Hess wrote:
> On Mar 24, 2007, at 18:30, Adam Tauno Williams wrote:
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1852
> >
> > This seems useful, and overdue; it has come up on the mailing list
> > before although I can't seem to find the thread. It also seems
> > related
> > to Bug#1274
> >
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1274
> >
> > Outlook provides an IM address field and this is stored in the
> > im_address field of the person table. But it doesn't seem to provide
> > any way to specify what kind of IM service is being used; so I
> > like the
> > Bug#1852 solution better.
>
> Hm, yes. As mentioned IMHO an IM field is more like a phone number,
> though thats not typed further either. The UI would need to check the
> string contents to decide what to render.
> But I don't mind ;-)
>
>
> > Question #1) Is there any kind of policy/philosophy with regard to
> > adding new types of extended attributes?
> In general extattrs are bad because they slow down the system
> (different relation in the DB, lots of joins, assemble/dissably in
> the app etc).
> Eg email1 should have been company.email from the beginning (I think
> it was added later on).
Ah! I've always wondered about that.
> Now the questions was on "new types". Adding new types of course
> doesn't hurt, only people using more of them does ;-)
> What I always wondered is whether we are going to drop the
> 'company_value' and use 'obj_property' like other objects. But I
> suppose thats not going to happen in the OGo 5.x line given thats it
> is a larger change.
It would be nice to have just one mechanism for storing custom data. :)
> > Question #2) If the Bug#1852 solution is used perhaps we should
> > consider
> > created an extended attribute type of each of the *major* IM service
> > types so a corresponding URL can be generated. XMPP, OSCAR (AIM/ICQ),
> > MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and
> > 25?
> Good question. Can't we just have one IM type which stores the IM
> service URI. Like: aim:helje5?
Makes sense.
> Of course the component/element which shows the value must parse this
> for display. And the editor might need to support the user.
Something like: