Could a CALC sheet be used as a data container?

Support major spread sheet formats (Excel, Calc) with Tasks as first sheet (or
any sheet labeled Tasks), optional Resources as second sheet (or any sheet named
Resources), etc.

Integrate with PIM programs and calendaring standards, to allow project
contributors to see new task allocated to them (perhaps as task or meeting),
accept and acknowledge the task, and report back completion from PIM.

Perhaps it would be useful to allow the user to extract data into a 'custom'
spreadsheet that allows arbitrary field selection into a column and grouping of
rows.

Wide variety of flat file formats, including Microsoft Project Data Interchange.
 See http://proj.chbs.dk/specifications.

The integration with OOo should cover:
- look and feel of OOo
- links to attachments (through customized fields)
- integration with upcoming OOo calendar (Mozilla collaboration) for calendar
exchange (+standard calendar formats) 

Could an initial list of tasks and resources be imported from a CALC, Writer or
other plain text file.

The ability to import an initial list of tasks and resources from a CALC, Writer
or other plain text file.

Ability to import region specific public holidays as stored in an existing Open
Office file (such as the Calendar program)

@  jwrolf

forget support for proprietary data formats. we will definitely not re-engineer
a, forefront, badly analyzed data model and will have that be driving our
application's data model. (meaning Microsoft Project Data Interchange)

these formats, defined by a single entity alone, tend to change faster than you
might say and correctly pronounce "Quitschieboo".

besides that, the posted link is dead. this may be due to the fact that most of
the formats once presented there are actually proprietary.

we might add import and export to said proprietary formats in the future but
this will not be a requirement for the initial prototype nor for release 2.x,
unless people are willing to cope with an evolving datamodel and thus want to
include the export/import capability from the start, including constant
maintenance of the import/export components both in respect to internal changes
to the data model and also in respect to changes in the data model of the
external format, which, once functional might change faster than you might even
consider in order to keep them proprietary once more.

we still have to define an OASIS Open Document standard for OOPM documents.

@ hillerd

as for integration with calc, sure, we will have exports to calc, however, calc
will not be the driving force in our solution backend

@ gilh

we will provide for custom exports to embedded parts of the OOo suite, most
likely calc and writer.

@ jwrolf

PIM integration would be nice, but is not part of the intitial prototype and
will not be integrated before release version 2.

@ jwrolf

Supporting multiple spread sheet formats boils down to just supporting one
spread sheet format, namely that defined by the OASIS Open Document standard for
spread sheet exchange. Once loaded into the calc component of the OOo suite you
might always also export it to any format supported by calc.

@ fd64 

importing a calc spread sheet, once that the data model is made clear and has
been stabilized in some way or the other, should not impose that much of a
problem here

@ fd64

importing regional holidays and other special events in the regional calendar
should not be that much of a problem and will definitely be a part of the
solution in one of the later releases.

 

Reset assignee on issues not touched by assignee in more than 1000 days.

obsolete