From wrobel at pardus.de Tue Jul 1 17:03:20 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Tue, 01 Jul 2008 17:03:20 +0200 Subject: RFC: Format proposal for time tracking data Message-ID: <87iqvpmytj.fsf@home.pardus.de> Hi! I'd like to present a draft for an extension of the Kolab format. The purpose is to store time tracking data on the Kolab server. (Note: When responding to this mail, please keep it to the kolab-format at kolab.org list as long as it concerns the new data types presented here. I'm just cross posting this as there might be some people on the developers list interested in a time tracking tool, too). The following data types are suggested: The mimetype for time tracking data is "application/x-vnd.kolab.timetrack". This is the specification of the body contents: (string, no default) (string, default empty) (string, default empty)

(datetime, no default)

(string, default public) {(string, no default)} {(string, no default)} (string, default empty) (string, no default, not empty) (string, no default, not empty) (string, no default, not empty) (string, no default, not empty) (string, no default, not empty) (string, no default, not empty) (number, default 0) (number, default 0) (number, default 0) (number, no default) (string, default empty) (string, default empty) Description of the specific fields: - client: A cross reference to the client in a Kolab addressbook. The reference uses the UID of the address element. The application handling the time tracking data needs to be configured so that it knows how to cross reference the address book. - employee: The mail address of the employee that generated the time tracking data. - type: The UID of the job type. The job type has to be stored in the same IMAP folder as the time tracking data. - hours: A floating point number stored as string. It holds the amount of time spent on the item represented by this time track entry. - rate: The rate at which the time will be billed. This is fetched from the job type for this entry but is written into the time track entry for convenience. This is a floating point number stored as a string. - costobject: UID of a cost object on the server. This could be a task for example. The application handling the time tracking data needs to know how to cross reference cost objects on the server. - billable: Is this object billable (1) or not (0)? - submitted: Did the employee already submit the entry for review or invoice generation (1) or not (0)? - exported: Has the entry already been exported (1) or not (0)? E.g. into an invoice? - date: The day the time was spent. - description: A (required) description of the task. - note: Any additional notes. In addition it will be necessary to represent different job types. The mimetype for job type data is "application/x-vnd.kolab.jobtype". This is the specification of the body contents: (string, no default) (string, default empty) (string, default empty)

(datetime, no default)

(string, default public) {(string, no default)} {(string, no default)} (string, default empty) (string, default empty) (number, default 0) (number, default 0) (string, no default, not empty) Description of the specific fields: - name: The name of the job type - billable: Can this job type be billed (1) or not (0)? - enabled: Is this job type currently available (1) or not (0)? - rate: At which rate will this job type be billed (floating point number stored as a string)? Please take this only as a very early draft only meant for getting some comments and ideas. While the suggestion is only proposing a theoretical data format it is of course driven by an existing client application. Horde released "Hermes" (http://horde.org/hermes/) yesterday. This is a small time tracking application that interfaces nicely with the other Horde applications (addressbooks and tasks). I already wrote a Kolab driver for this app now but I'll keep this private as long as there is no common format we can agree on. I hope there are some other devs that would like to use time tracking on the Kolab server, too. Cheers, Gunnar -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bernhard at intevation.de Wed Jul 2 12:47:45 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 2 Jul 2008 12:47:45 +0200 Subject: [Kolab-devel] RFC: Format proposal for time tracking data In-Reply-To: <87iqvpmytj.fsf@home.pardus.de> References: <87iqvpmytj.fsf@home.pardus.de> Message-ID: <200807021247.48707.bernhard@intevation.de> Gunnar, On Tuesday 01 July 2008 17:03, Gunnar Wrobel wrote: > Please take this only as a very early draft only meant for getting > some comments and ideas. thanks for publishing the draft. My idea is to get spec 2.0 released and then set up a better process for going from there. Doing draft releases or KEPs (Kolab Enhancement Proposals) is a good idea. I guess we should track them somewhere, e.g. in the Wiki. > While the suggestion is only proposing a theoretical data format it > is of course driven by an existing client application. > > Horde released "Hermes" (http://horde.org/hermes/) yesterday. This is > a small time tracking application that interfaces nicely with the > other Horde applications (addressbooks and tasks). I already wrote a > Kolab driver for this app now but I'll keep this private as long as > there is no common format we can agree on. > > I hope there are some other devs that would like to use time tracking > on the Kolab server, too. Of course it would be fine to have a format for this. You've missed how many folders you would propose for this? Also for a good completion we should look at how other clients do it, so that our first move is already good enough to cover a large section of the problem space. Clients like "worklog" (which I use for timetracking) or KArm and whatever people use on Windows/Outlook. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20080702/46d850a0/attachment.bin From wrobel at pardus.de Thu Jul 3 07:29:27 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 03 Jul 2008 07:29:27 +0200 Subject: [Kolab-devel] RFC: Format proposal for time tracking data In-Reply-To: <200807021247.48707.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 2 Jul 2008 12:47:45 +0200") References: <87iqvpmytj.fsf@home.pardus.de> <200807021247.48707.bernhard@intevation.de> Message-ID: <87bq1fk020.fsf@home.pardus.de> Bernhard Reiter writes: > Gunnar, > > On Tuesday 01 July 2008 17:03, Gunnar Wrobel wrote: >> Please take this only as a very early draft only meant for getting >> some comments and ideas. > > thanks for publishing the draft. > My idea is to get spec 2.0 released and then set up a better process > for going from there. Doing draft releases or KEPs (Kolab Enhancement > Proposals) is a good idea. I guess we should track them somewhere, > e.g. in the Wiki. Yes, Wiki would be good. > >> While the suggestion is only proposing a theoretical data format it >> is of course driven by an existing client application. >> >> Horde released "Hermes" (http://horde.org/hermes/) yesterday. This is >> a small time tracking application that interfaces nicely with the >> other Horde applications (addressbooks and tasks). I already wrote a >> Kolab driver for this app now but I'll keep this private as long as >> there is no common format we can agree on. >> >> I hope there are some other devs that would like to use time tracking >> on the Kolab server, too. > > Of course it would be fine to have a format for this. > You've missed how many folders you would propose for this? Yes, I forgot that. The current implementation uses a single IMAP folder of type "timetrack". But now that you asked I thought about it again and I believe it might actually make sense to store it alongside with the associated tasks. Horde currently allows to assign time track data to so called "cost-objects". As far as I know these may be tasks and bugs (in the Horde bug tracker called "whups"). So for Kolab time tracking currently only works with tasks. Each time track object now carries a cross-reference to the UID of the task (element "cost-object" in the schema I proposed). I actually don't like using a reference across IMAP folders too much. Currently such references are still left undefined by the Kolab format if I'm not mistaken. I believe we should tackle that problem at some point and also clarify on how UIDs are to be used. But for the specific task of storing time tracking data I think it would also make sense to store it directly in the IMAP folder of the associated tasks. > Also for a good completion we should look at how other clients do it, > so that our first move is already good enough to cover a large section of the > problem space. Absolutely. That is the main reason why I posted this. I would like to have at least one other candidate application that might have a chance of implementing this in the forseeable future. > > Clients like "worklog" (which I use for timetracking) or KArm and whatever > people use on Windows/Outlook. I checked KArm (which has been renamed to KTimeTracker for KDE4.0) and I believe it has the necessary potential to become another Kolab client app for time tracking. It integrates with Korganizer and can be used as a plugin in Kontact. That sounds good to me. http://wiki.kde.org/ktimetracker I'll have a look at this and will check what type of data it generates. "worklog" did not see any development over the past four years if I'm not mistaken. And as it is also a web app I guess it would be easier to cover that ground with Horde. Cheers, Gunnar > > Bernhard > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Kolab-format mailing list > Kolab-format at kolab.org > https://kolab.org/mailman/listinfo/kolab-format -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From martin.konold at erfrakon.de Thu Jul 3 09:27:14 2008 From: martin.konold at erfrakon.de (Martin Konold) Date: Thu, 3 Jul 2008 09:27:14 +0200 Subject: [Kolab-devel] RFC: Format proposal for time tracking data In-Reply-To: <87bq1fk020.fsf@home.pardus.de> References: <87iqvpmytj.fsf@home.pardus.de> <200807021247.48707.bernhard@intevation.de> <87bq1fk020.fsf@home.pardus.de> Message-ID: <200807030927.19646.martin.konold@erfrakon.de> Am Donnerstag 03 Juli 2008 schrieb Gunnar Wrobel: Hi Gunnar, > >> Please take this only as a very early draft only meant for getting > >> some comments and ideas. > > > > thanks for publishing the draft. Can you please resend the draft to my mail address? In general I am wondering how time tracking relates to the already available Journals etc. Regards, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From bernhard at intevation.de Fri Jul 4 10:00:21 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 4 Jul 2008 10:00:21 +0200 Subject: [Kolab-devel] RFC: Format proposal for time tracking data In-Reply-To: <87bq1fk020.fsf@home.pardus.de> References: <87iqvpmytj.fsf@home.pardus.de> <200807021247.48707.bernhard@intevation.de> <87bq1fk020.fsf@home.pardus.de> Message-ID: <200807041000.22258.bernhard@intevation.de> Gunnar, On Thursday 03 July 2008 07:29, Gunnar Wrobel wrote: > Absolutely. That is the main reason why I posted this. I would like to > have at least one other candidate application that might have a chance > of implementing this in the forseeable future. yes, this should we a criteria for uptake in a regular released Kolab Storage Format spec I would say. > > Clients like "worklog" (which I use for timetracking) or KArm and > > whatever people use on Windows/Outlook. > > I checked KArm (which has been renamed to KTimeTracker for KDE4.0) and > I believe it has the necessary potential to become another Kolab > client app for time tracking. It integrates with Korganizer and can be > used as a plugin in Kontact. That sounds good to me. > > http://wiki.kde.org/ktimetracker > > I'll have a look at this and will check what type of data it > generates. Very cool! As you've liked the wiki, opening a page up there would be cool as well. ;) > "worklog" did not see any development over the past four years if I'm > not mistaken. And as it is also a web app I guess it would be easier > to cover that ground with Horde. I am using worklog for a couple of reasons and what is important is that our format should not just be completed guided by the current implementations and their formats, but by an analysis of the problem at hand, which includes the workflow. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20080704/e63111e3/attachment.bin From bernhard at intevation.de Tue Jul 8 14:12:16 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Jul 2008 14:12:16 +0200 Subject: start-date and end-date mandatory for events Message-ID: <200807081412.21794.bernhard@intevation.de> It looks like there is a small ambiguity in the events format specification. The "default not present" could lead to missinterpretations for the event as I do not think there are appointment without those tags. They both are mandatory as already somehow pointed out by that they are not in curly brakets. I also do not think that empty is okay for those tags. Thus I am going to commit the following change: RCS file: /kolabrepository/doc/kolab-formats/events.sgml,v retrieving revision 1.14 diff -u -r1.14 events.sgml --- events.sgml 22 Jul 2005 19:29:59 -0000 1.14 +++ events.sgml 8 Jul 2008 12:08:06 -0000 @@ -24,7 +24,7 @@ (string, default empty) (string, default empty) - (date or datetime, default not present) + (date or datetime) (number, no default) (number, default 1) @@ -46,7 +46,7 @@

(string, default busy)

(string, default none) - (date or datetime, default not present) + (date or datetime) ]]> -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-format/attachments/20080708/5a005dce/attachment.bin From wrobel at pardus.de Thu Jul 10 12:03:23 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 10 Jul 2008 12:03:23 +0200 Subject: [Kolab-devel] RFC: Format proposal for time tracking data In-Reply-To: <200807030927.19646.martin.konold@erfrakon.de> (Martin Konold's message of "Thu, 3 Jul 2008 09:27:14 +0200") References: <87iqvpmytj.fsf@home.pardus.de> <200807021247.48707.bernhard@intevation.de> <87bq1fk020.fsf@home.pardus.de> <200807030927.19646.martin.konold@erfrakon.de> Message-ID: <87mykq839w.fsf@home.pardus.de> Hi Martin, Martin Konold writes: > Am Donnerstag 03 Juli 2008 schrieb Gunnar Wrobel: > > Hi Gunnar, > >> >> Please take this only as a very early draft only meant for getting >> >> some comments and ideas. >> > >> > thanks for publishing the draft. > > Can you please resend the draft to my mail address? it is archived here: http://www.kolab.org/pipermail/kolab-format/2008-July/000862.html > > In general I am wondering how time tracking relates to the already available > Journals etc. The journal entries have a start and an end date. So the core element of time tracking is there. It might be possible to extend that format. Cheers Gunnar > > Regards, > -- martin > > -- > e r f r a k o n > Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker > Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 > http://www.erfrakon.com/ > > _______________________________________________ > Kolab-format mailing list > Kolab-format at kolab.org > https://kolab.org/mailman/listinfo/kolab-format -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From wrobel at pardus.de Thu Jul 10 12:05:37 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 10 Jul 2008 12:05:37 +0200 Subject: [Kolab-devel] RFC: Format proposal for time tracking data In-Reply-To: <200807041000.22258.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 4 Jul 2008 10:00:21 +0200") References: <87iqvpmytj.fsf@home.pardus.de> <200807021247.48707.bernhard@intevation.de> <87bq1fk020.fsf@home.pardus.de> <200807041000.22258.bernhard@intevation.de> Message-ID: <87iqve8366.fsf@home.pardus.de> Bernhard Reiter writes: > Gunnar, > > On Thursday 03 July 2008 07:29, Gunnar Wrobel wrote: >> Absolutely. That is the main reason why I posted this. I would like to >> have at least one other candidate application that might have a chance >> of implementing this in the forseeable future. > > yes, this should we a criteria for uptake in a regular released Kolab Storage > Format spec I would say. > >> > Clients like "worklog" (which I use for timetracking) or KArm and >> > whatever people use on Windows/Outlook. >> >> I checked KArm (which has been renamed to KTimeTracker for KDE4.0) and >> I believe it has the necessary potential to become another Kolab >> client app for time tracking. It integrates with Korganizer and can be >> used as a plugin in Kontact. That sounds good to me. >> >> http://wiki.kde.org/ktimetracker >> >> I'll have a look at this and will check what type of data it >> generates. > > Very cool! As you've liked the wiki, opening a page up there would > be cool as well. ;) Will do that soon. > >> "worklog" did not see any development over the past four years if I'm >> not mistaken. And as it is also a web app I guess it would be easier >> to cover that ground with Horde. > > I am using worklog for a couple of reasons and what is important is that our > format should not just be completed guided by the current implementations and > their formats, but by an analysis of the problem at hand, which includes the > workflow. Sure. Would be just interesting to know what your specific requirements in that case are. The recently released "Hermes" is still very open to new types of functionality. I also added some code to suite my own workflow. Cheers, Gunnar > > Bernhard > > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Kolab-format mailing list > Kolab-format at kolab.org > https://kolab.org/mailman/listinfo/kolab-format -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~