Forum OpenACS Q&A: Response to Who wants to built .WRK?

Posted by Torben Brosten on
Simon, I totally agree that dotWRK should not be software-project centric.  The data models should be simple, yet flexible. This means having a built-in short-list of functions, such as:

1. "Log" package - posts "description", "done by", "date" with options to activate/display fields in "duration", "confirmed by", "authorized by", "comments/notes" "WBS/outline reference" "job code" "status" etc. where fields displayed can be filtered/sorted by content, and ability to add or change values and headings based on permissions.

2. accounting package with simple ledger functionality (account, item ref, original date, to/from, for/exp-code, credit/debit, project/client ref, their ref, statement date, papers filed, tax ref etc.), and again extra fields (other1, other2) included (so a DB/OpenACS expert doesn't have to get involved everytime a project is a little different) --saves time for everyone.

3. time ledger package that integrates with calendar (adds and removes alerts to it as schedule changes). again, extra fields

4. research package/info-log that tracks progress of unknowns to facts. This could be a table consisting of fields: Info type - (about subject from other than subject, from itself, from subject about other), entry date, citation/source, comments etc.  Subject may be Person, Entity, Witness, Topic, Product/project feasibility...

All four of these are a variation on a cluster of similar functions and procedures that perhaps can be rolled into one package and mounted/configured in different ways --more than one instance working in the same "realm"    ....perhaps integrating across package instances  hmm.. that may be too much too fast! =)

Many times, extra functionality is not as important as an appropriate place to put the info, authority to edit/change it, and ability to customize how it is reported.

The packages should include a few extra blank long fields with generic field names--where the displayed fieldnames can be changed.

Also, the ability to export/import to/from a spreadsheet (as tab delimited text or CSV) would be useful in case some field data needs changed based on functions or batch editing, for charting etc.

Perhaps some fields could contain custom calculations... starting with (filtered) pure tcl represented 1 line equations that reference other fields in the same table set...

think customizable, flexible, integrable