coils-project Mailing List for OpenGroupware Coils
Status: Beta
Brought to you by:
whitemice
Menu
▾
▴
coils-project — Discussion of Coils project related issues
You can subscribe to this list here.
| 2010 |
Jan
(1) |
Feb
(18) |
Mar
(5) |
Apr
(1) |
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(1) |
Sep
(17) |
Oct
(9) |
Nov
(35) |
Dec
(57) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(38) |
Feb
(8) |
Mar
(8) |
Apr
(12) |
May
(8) |
Jun
(16) |
Jul
(2) |
Aug
(15) |
Sep
(2) |
Oct
(1) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(4) |
Jun
|
Jul
(15) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2013 |
Jan
(7) |
Feb
(22) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Adam T. W. <awi...@wh...> - 2013-04-08 10:47:19
|
I ran across another WebDAV client of Sourceforge - this is a Java utility to synchronize a local folder with a WebDAV collection. That could be interesting / useful. <https://sourceforge.net/projects/webdav-sync/> I've create a 'stub' Wiki page for the client and a ticket to track any testing. <https://sourceforge.net/p/coils/tickets/158/> <https://sourceforge.net/p/coils/wiki/WebDAV%20Sync/> |
|
From: Adam T. W. <awi...@wh...> - 2013-04-08 10:37:03
|
Recent Changes -------------- Since 0.1.49rc33 one important change has been merged into the SMTP Listener. Rather than queuing incoming message for processing as a tuple of (from, to, message) where "message" is a email message object the messages are now queued as (from,to,attachment-guid) and the message is now serialized to an Attachment object. This allows a greater queue as messages are now stored in-memory which can be problematic when there is a high rate of incoming messages. The Attachment objects are deleted once a message has been processed from the queue. When serialized these attachments have a MIME-type of "message/rfc822" and a kind of "opengroupware:smtp:message/rfc822". This improvement increases the usefulness of the email-to-document function of the SMTP listener as a steady stream of incoming documents can now be easily managed. A few more bugs/tickets have been created in the dangling-fruit category as well [see below for how to access the dangling-fruit bug list]. WMOGAG Coils Manual -------------------------------------------- An edition of the Whitemice Consulting OpenGroupware Adminsitrator's Guide Coils Edition is available at the SourceForge project. <http://sourceforge.net/projects/coils/files/WMOGAG-Coils.pdf/download> Not a developer, but want to help out the project? Consider helping out edit WMOGAG. Report errors or problems to the list and you'll be listed as a contributor to the document. Follow Us ------------------------------------------- Don't forget to follow "opengroupware" on Twitter and/or identi.ca <http://identi.ca/opengroupware> <http://twitter.com/opengroupware> Not a developer, but want to help out the project, help up market on all these myriad "social networking" facilities. Mercurial MQ & Patch Queues --------------------------- Several new Mercurial (Hg) repositories have been created in the Coils project; these are for use with the Mercurial MQ extension [which is supported in TortoiseHg with a new GUI]. MQ provides "patch queues" that are quasi-subordinate repositories; patch queues are a nice way of storing, sharing, and exchanging change sets (patches). Patches in a queue can be applied, unapplied, reordered, updated... without changes to the core repository - they are 'finished' to the core reposistory when they are finished. :) This avoids the core repository being used as "Save As" and makes a commit == some-work-is-finished! Which is what "commit" is supposed to mean. Everyone is free to continue to use their own branch any way they like, of course. But patch queues should help us clean up how the commit log looks. It is also just much easier than having a whole bunch of 'personal' branches where one works on different stuff; as commit often tend to run across branches. To use a patch queue - 1. Enable the MQ extension. 2. Go in to the .hg [hidden] subfolder and clone the patch queue. Exit TortoiseHg, or whatever your version control tool is cd .hg hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/cmis patches-CMIS Edit patches.queues, adding the name of the queue, like: # cat patches.queues patches CMIS NOTE: The "patches-" prefix is assumed on patch queue sub-folder -> patch queue mapping. The patches.queues is a list of the installed/available patch queues. You can have none, one, some, or all the patch queues. It is easiest, I think, to just do them all - but you only need to do the ones you want to do. Just always edit this with your version control interface shutdown. Start TortoiseHg, or whatever your version control tool is. OpenGroupware Coils Patch Queue Repositories -------------------------------------------- Pathes: This patch queue is for patches that implement specific new features or triage specific bugs. Please one bug/feature per patch. Patch Repo: hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/patches patches CMIS: This queue is for implementation of the CMIS v1.0 protocol; this will allow full interoperation with document management features of LibreOffice and Microsoft Office. And it is just a really good protocol with lots of miscelaneous implementations - and it very much already matches how OpenGroupware manages documents. Each patch should be an implementation of some part of the protocol; in the queue the patches are meant to be applied as a stack. Wiki Page: https://sourceforge.net/p/coils/wiki/CMIS-REST/ Patch Repo: hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/cmis patches-CMIS Async: This queue is for porting of the gnarly HTTP service provider to the Tornado HTTP engine. I imagine it will be an entire stack of patches as this will make little touches to everyting under coils/protocol and coils/net. Wiki Page: https://sourceforge.net/p/coils/wiki/Tornado/ Patch Repo: hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/async patches-Async OIE: This queue is for enhancement and bug fixes to OIE (the workflow engine). Please one enhancement / fix per patch. Patch Repo: hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/oie patches-OIE Logos Logos Logos ------------------------------------------- The OpenGroupware Coils project needs a logo; and maybe OIE needs it won sub-logo? If you've got graphic design skills submit your idea. Submission of the logo will *require* joining the project list [here!] and posting a message clearly stating that you are transferring the copyright of the logo to the OpenGroupware Coils project and the design is under a creative-commons license. <>http://creativecommons.org/choose/ You must allow commercial use [1] and modification. [1] OpenGrouwpare Coils is MIT/X11 licensed specifically to *allow* commercial use and modification. Just like Mono, F-Spot, Banshee, and all the other coolest projects. :) Dangling Fruit ------------------------------------------- In an effort to allow new developers to put there toe-in-the-water with Coils I've creating a "Dangling Fruit" bug list. <https://sourceforge.net/apps/trac/coils/query?status=! closed&order=priority&report=9&keywords=~dangling-fruit> Bugs that should be fairly simple to implement or fix will have the "dangling-fruit" keyword which will cause them to automatically appear on that list. At first this will include a lot of the Macro commands to be used in Map functionality (the ability to construct patterns of ladder like logic that can be applied when transforming data via a Format). Testing A Macro ------------------------------------------- FYI, testing MacroCommands doesn't require a working database. from coils.logic.workflow import * m = AdditionMacro() m.parse_parameters(var1=10, var2=11.5) m.run() m.get_result() 21.5 This won't work for macro's like SQLLookupMacro which require an initialized backend; but most macros are very simple and should work without initialization. Requests For Help ------------------------------------------- Want to implement something cool and exciting; here are a couple of ideas for 'big' ways to help-out the OpenGroupare Coils project: - MAPI Support OpenGroupware Coils is a Python based collaboration platform. Seeking a C programmer to investigate creating an connector between OpenChange and OpenGroupware Coils. OpenChange is a MAPI server that allows Outlook to communicate with backends other than Exchange via it's MAPI protocol.] The C "plugin" for OpenChange could simply serialize the requests as AMQ messages to the Python Coils server which could generate the response so the C layer could be thin. A prototype MAPI store for SQLite can be seen at <http://websvn.openchange.org/listing.php?repname=OpenChange&path= %2Ftrunk%2Fmapiproxy%2Flibmapistore%2Fbackends% 2F&#a54bfe9fad865a91525f8e14cc96f2b74> . - Refactor in Twisted or $framework Current Coils implements its own HTTP request handler using Python's basic HTTP server. This works. But it would probably be better to refactor at least the request handler to use something better tested and 'theoretically' more scalable. Any pointers, directions, contributions in this area would be appreciated. This could possibly also improve our usable of the AMQ message bus. Mail Etiquette Reminder ------------------------------------------- The coils-project list has clear etiquette guidelines; please adhere to them when posting. Remember the mail list serves as an *archive* as well as a communications resource - so your messages, and their structure, should consider someone reading the thread six months from now. 1. Absolutely no HTML postings. Fix your e-mail client. 2. Use inline quoting and response. Do not top-post. Top-posted messages are *very* difficult for subsequent readers to understand. 3. Do not hi-jack threads. To start a new topic post a new message. If you think you should stay in the same thread but the topic has changed reply but change the subject to the form of "New Subject [Was: Old Subject] 4. Please limit the use of attachments on the list. PGP/GPG and S/MIME attachments are OK. We encourage all and any use of PGP/GPG! 5. This list is about the OpenGroupware Coils project. Do not post off-topic content. 6. Be friendly, positive, and specific. Request For Comments (Roles) ------------------------------------------- OpenGroupware Coils needs to implement roles - such as the ability to grant administrative powers to a user / group of users. My thought is to allow roles to be assigned to teams via defaults like: coils-server-config --directive "CoilsRoleAssignments" --value '{ "Administration": "{OGO-TEAM-NAME}", "OtherRole": "OGO-TEAM-NAME"}' This keeps compatibility with OGo Legacy and seems fairly straight forward. Although it does lead to a tendency of creating many teams, which can clutter a UI. Request For Comments (Data Mapping) ------------------------------------------- Thoughts and comments on implementing the following are appreciated. In BIE/BIE-gpl (which is one of the applications/services) that OpenGroupware Coils [via OIE] seeks to replace they had, quite possibly, one of the best data mapping tools ever created. OIE now has Format classes that easily surpass what was available in BIE for importing and exporting file formats, but we still lack anything like their data mapping capability. NOTE: for clarity I uploaded a screenshot of the BIE data mapping application to the Screenshot's portion of the SF project <https://sourceforge.net/project/screenshots.php?group_id=268469> since a picture explains a lot. I've ported all of my employers routes that don't use the mapper from BIE to OIE and everything is working great! But now I face implementing something like that awesome mapper. Essentially what is does is perform an xpath foreach on the source and upon each element it runs it through a ladder-logic like system where macros can be applied to the element producing a [potentially] modified output. In BIE's mapper one had an input format mapped to an output format. If we were simply rewriting a record of the same format I think it would be possibly to specify the map with something like - import yaml m = { 'name': 'mymap', 'xpath': '/ResultSet/row', 'rules': [ { 'id': 'rule1', 'macro': 'if-condition', 'params': { 'expression': '==', 'left': '/system_source', 'right': 'MS' } }, { 'id': 'rule2', 'macro': 'eval-condition', 'params': { 'bool': '$rule1', 'true': 'XYZ', 'false': 'oem_code' } }, { 'id': 'rule3', 'macro': 'math-multiply', 'params': { 'arg1': '/quantity', 'arg2': '/sale_amount' } }, { 'id': 'rule4', 'macro': 'eval-condition', 'params': { 'bool': '$rule1', 'true': '$rule3', 'false': '/sale_amount' } } ], 'target': [ { 'id': 'rule4', 'xpath': '/sale_amount' }, { 'id': 'rule2', 'xpath': '/oem_code' } ] } yaml.dump(m) name: mymap rules: - action: if-condition id: rule1 params: {expression: ==, left: /system_source, right: MS} - action: eval-condition id: rule2 params: {bool: $rule1, 'false': oem_code, 'true': XYZ} - action: math-multiply id: rule3 params: {arg1: /quantity, arg2: /sale_amount} - action: eval-condition id: rule4 params: {bool: $rule1, 'false': /sale_amount, 'true': $rule3} target: - {id: rule4, xpath: /sale_amount} - {id: rule2, xpath: /oem_code} xpath: /ResultSet/row - where arguments starting with '$' use the results of a previous rule [ladder-logic style] and arguements starting with '/' specify an xpath to a value in the input element. Macros could just be an command type, discovered in the same manner as workflow actions; parameters could just be resolved and mapped directly to the command. The target stanza of the map specification can then map rule results to xpath values in the element which would then be written out. SOPE (from OpenGroupware Legacy) had a rule engine that is conceptually similar to this as well, and might merit reading. I've stowed those docs in the repo <http://coils.hg.sourceforge.net/hgweb/coils/coils/file/a58458f07ee5/src/coils/logic/workflow/actions/format/docs/SOPERuleEngine.txt> Also I stowed an example of a reasonably complex map definition from BIE-gpl <http://coils.hg.sourceforge.net/hgweb/coils/coils/file/a58458f07ee5/src/coils/logic/workflow/actions/format/docs/HederaPartsCSV2HederaPartsSQL.xml> The value of something like this when importing data from foreign sources can't be overstated. OIE has already implemented a [lame] solution for a couple macros as individual actions but that seems inefficient and really adds to route complexity. |
|
From: Adam T. W. <awi...@wh...> - 2013-04-08 10:15:59
|
OpenGroupware Coils 0.1.49rc33 has been uploaded to SF & PyPI. <http://www.opengroupware.us/2013/04/opengroupware-coils-0149rc33-released.html> I've also released a few new articles onto the BLOG. * Starting & Stopping Process Invocation <http://www.opengroupware.us/2013/04/starting-stopping-process-invocation.html> * Coils Specific Properties via WebDAV <http://www.opengroupware.us/2013/03/coils-specific-properties-via-webdav.html> *AttachFS PUT to Projects and Tasks <http://www.opengroupware.us/2013/03/attachfs-put-to-projects-and-tasks.html> *Improvements to the SMTP Listener <http://www.opengroupware.us/2013/03/the-smtp-listener.html> |
|
From: Adam T. W. <awi...@wh...> - 2013-02-20 01:49:28
|
OpenGroupware Coils 0.1.49rc25 has been uploaded to SF & PyPI Changes -------- * Support for specification of target tableName in sqlInsertAction via parameter which overrides tableName provided in the ResultSet element of the input message. Label substitution support for this value. * Rendering of records read via a SimpleFixedFieldFormat to StandardXML is now performed using ElementFlow. * BUGFIX: BLOBManager now correctly sets the max core size of scratch files again. * Archived tasks are not included by default in the _TASK keyof the Omphalos representation of a project. Set the server default "OmphalosIncludeArchivedProjectTasks" to "YES" to revert to the previous behavior of including archived tasks. * Documents can now be uploaded using AttachFS via a Task. * Support for INBOXing documents uploaded to Projects via a related entity has been implemented. * BUGFIX: Content-Length header of a 201 response from AttachFS is always zero. * Every task created is now assigned a UID if the client did not provide one. * Added get_anchor API call to zOGI; this allows retrieval of collection CTAG values via zOGI. * BUGFIX: The ".ctag" REST key on a Teams collection was not available. * The coils-fix-nocomplete-tasks tool now includes archived tasks. |
|
From: Adam T. W. <awi...@wh...> - 2013-02-18 13:59:39
|
On Mon, 2013-02-18 at 07:00 -0500, Adam Tauno Williams wrote: > Mercurial MQ & Patch Queues > --------------------------- > OpenGroupware Coils Patch Queue Repositories > -------------------------------------------- > Pathes: > CMIS: > Async: > OIE: NOTE: These patches are in patch queues and not committed to the report BECAUSE THEY MAY BREAK THINGS! That is what patch queues are for. :) Just clarifying, after rereading my message I thought I didn't make that part very clear. Clarity is good. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Adam T. W. <awi...@wh...> - 2013-02-18 13:03:03
|
On Mon, 2013-02-18 at 07:39 -0500, Steve Romanow wrote: > That all looks very nice Adam. It is pretty slick how it works; and the TortioseHg provides a pretty intuitive UI for such an actually complex thing. This is usable without have a contributor know all the grit about version control. And DVCS's can become a huge time-eater in themselves in all the 'cool' ways you can do things - keeping you for ever getting around to actually doing anything. |
|
From: Steve R. <sle...@gm...> - 2013-02-18 12:39:50
|
That all looks very nice Adam.
On Feb 18, 2013 7:00 AM, "Adam Tauno Williams" <awi...@wh...>
wrote:
Mercurial MQ & Patch Queues
---------------------------
I've create several new Mercurial (Hg) repositories in the OpenGrouwpare
Coils project; these are for use with the Mercurial MQ extension [which
is supported in TortoiseHg with a new GUI]. MQ provides "patch queues"
that are quasi-subordinate repositories; patch queues are a nice way of
storing, sharing, and exchanging change sets (patches). Patches in a
queue can be applied, unapplied, reordered, updated... without changes
to the core repository - they are 'finished' to the core reposistory
when they are finished. :) This avoids the core repository being used
as "Save As" and makes a commit == some-work-is-finished! Which is what
"commit" is supposed to mean.
Everyone is free to continue to use their own branch any way they like,
of course. But patch queues should help us clean up how the commit log
looks. It is also just much easier than having a whole bunch of
'personal' branches where one works on different stuff; as commit often
tend to run across branches.
To use a patch queue -
1. Enable the MQ extension.
2. Go in to the .hg [hidden] subfolder and clone the patch queue.
Exit TortoiseHg, or whatever your version control tool is
cd .hg
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/cmis patches-CMIS
Edit patches.queues, adding the name of the queue, like:
# cat patches.queues
patches
CMIS
NOTE: The "patches-" prefix is assumed on patch queue sub-folder ->
patch queue mapping. The patches.queues is a list of the
installed/available patch queues. You can have none, one,
some, or all the patch queues. It is easiest, I think, to
just do them all - but you only need to do the ones you want
to do. Just always edit this with your version control
interface shutdown.
Start TortoiseHg, or whatever your version control tool is.
OpenGroupware Coils Patch Queue Repositories
--------------------------------------------
Pathes:
This patch queue is for patches that implement specific new features
or triage specific bugs. Please one bug/feature per patch.
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/patches patches
CMIS:
This queue is for implementation of the CMIS v1.0 protocol; this will
allow full interoperation with document management features of
LibreOffice and Microsoft Office. And it is just a really good
protocol with lots of miscelaneous implementations - and it very much
already matches how OpenGroupware manages documents. Each patch
should be an implementation of some part of the protocol; in the queue
the patches are meant to be applied as a stack.
Wiki Page: https://sourceforge.net/p/coils/wiki/CMIS-REST/
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/cmis patches-CMIS
Async:
This queue is for porting of the gnarly HTTP service provider to
the Tornado HTTP engine. I imagine it will be an entire stack of
patches as this will make little touches to everyting under
coils/protocol and coils/net.
Wiki Page: https://sourceforge.net/p/coils/wiki/Tornado/
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/async patches-Async
OIE:
This queue is for enhancement and bug fixes to OIE (the workflow
engine). Please one enhancement / fix per patch.
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/oie patches-OIE
--
Adam Tauno Williams <awi...@wh...>
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly
thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Coils-project mailing list
Coi...@li...
https://lists.sourceforge.net/lists/listinfo/coils-project
|
|
From: Adam T. W. <awi...@wh...> - 2013-02-18 12:00:26
|
Mercurial MQ & Patch Queues
---------------------------
I've create several new Mercurial (Hg) repositories in the OpenGrouwpare
Coils project; these are for use with the Mercurial MQ extension [which
is supported in TortoiseHg with a new GUI]. MQ provides "patch queues"
that are quasi-subordinate repositories; patch queues are a nice way of
storing, sharing, and exchanging change sets (patches). Patches in a
queue can be applied, unapplied, reordered, updated... without changes
to the core repository - they are 'finished' to the core reposistory
when they are finished. :) This avoids the core repository being used
as "Save As" and makes a commit == some-work-is-finished! Which is what
"commit" is supposed to mean.
Everyone is free to continue to use their own branch any way they like,
of course. But patch queues should help us clean up how the commit log
looks. It is also just much easier than having a whole bunch of
'personal' branches where one works on different stuff; as commit often
tend to run across branches.
To use a patch queue -
1. Enable the MQ extension.
2. Go in to the .hg [hidden] subfolder and clone the patch queue.
Exit TortoiseHg, or whatever your version control tool is
cd .hg
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/cmis patches-CMIS
Edit patches.queues, adding the name of the queue, like:
# cat patches.queues
patches
CMIS
NOTE: The "patches-" prefix is assumed on patch queue sub-folder ->
patch queue mapping. The patches.queues is a list of the
installed/available patch queues. You can have none, one,
some, or all the patch queues. It is easiest, I think, to
just do them all - but you only need to do the ones you want
to do. Just always edit this with your version control
interface shutdown.
Start TortoiseHg, or whatever your version control tool is.
OpenGroupware Coils Patch Queue Repositories
--------------------------------------------
Pathes:
This patch queue is for patches that implement specific new features
or triage specific bugs. Please one bug/feature per patch.
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/patches patches
CMIS:
This queue is for implementation of the CMIS v1.0 protocol; this will
allow full interoperation with document management features of
LibreOffice and Microsoft Office. And it is just a really good
protocol with lots of miscelaneous implementations - and it very much
already matches how OpenGroupware manages documents. Each patch
should be an implementation of some part of the protocol; in the queue
the patches are meant to be applied as a stack.
Wiki Page: https://sourceforge.net/p/coils/wiki/CMIS-REST/
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/cmis patches-CMIS
Async:
This queue is for porting of the gnarly HTTP service provider to
the Tornado HTTP engine. I imagine it will be an entire stack of
patches as this will make little touches to everyting under
coils/protocol and coils/net.
Wiki Page: https://sourceforge.net/p/coils/wiki/Tornado/
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/async patches-Async
OIE:
This queue is for enhancement and bug fixes to OIE (the workflow
engine). Please one enhancement / fix per patch.
Patch Repo:
hg clone ssh://{YOURNAME}@hg.code.sf.net/p/coils/oie patches-OIE
--
Adam Tauno Williams <awi...@wh...>
|
|
From: Adam T. W. <awi...@wh...> - 2013-02-12 12:30:24
|
Some new tickets have been added to the dangling-fruit ["these should be easy"] list - http://bit.ly/YnVyHt Changes have been merged into default branch: - Egg version has been bumped to 0.1.49rc24 * AttachFS allows put'ing a document to a Task entity. Where OGo#13871405 is a Task this will create/update the file named "cert.pem" in the root folder of the project this task is assigned to. It will also, automatically, generate an object link from the task to this new or updated file. curl -u adam -T cacert.pem \ "http://coils.example.com/attachfs/13871405/cacert.pem?mode=file" If the Task is not assigned to a project an exception will be raised. For storing arbitrary content on arbitrary tasks use attachment mode. Ticket 118 * AttachFS allows put'int a document to a Project entity. This performs the same operation as if the document was PUT to the root folder of the Project. Ticket 116 * Upon creation or update of a document (file mode) AttachFS no longer specifies the Content-Length of the object; Content-Length is not specified. Inclusion of Content-Length in the 201 response confused some proxy servers resulting in a long delay until connection timeout. Then Coils got blamed for being "slow". * When a Task is created via Logic a GUID is generated if one was not specified by the client. Generally a UID (GUID) would be assigned to the task when created by a GroupDAV/CardDAV client. Having one in advance eases syncronization by providing a better anchor for the client to use in its cache. * The new coils-fix-no-guid tool (script) will generate GUIDs/UIDs for Task and Contact entities in the database that do not have a UID value. * A new zOGI method getAnchor (available via XML-RPC currently) has been created that allows a client to check syncronization anchors in a 'normal' way. This is similar to how a WebDAV client would use the "ctag" attribue of a collection. A BLOG post about this new methd will be posted soon. * Operation of the ".ctags" special key on the /dav/Tasks collection has been fixed. Ticket 115 * The coils-fix-no-complete-tasks tool (script) now examines tasks in an archived state as well as those just done/rejected. * The XLS reader format now supports "discardMalformedRecords". This format has received an long overdue overhaul. It now generates its output using ElementFlow. * The new iconvAction allows messages (assumed to be of some text-like content) to be translated between specified encodings. * A new CoilsDateFormatException has been introduced and is raised in the case of a date string that cannot be parsed by the server. This makes the cause of a problem more evident to the client/user. * A user-agent description has been created for the WDFS WebDAV client. |
|
From: Adam T. W. <awi...@wh...> - 2013-02-10 21:07:53
|
> I had wondered if it was a problem with some invisible but extraneous > characters in the xml taken from the PDF file. However, I'd opened > the PDF on the same platform where I was doing the test, so one would > hope that such problems would have been mitigaged, but the sample xml > still would not parse. > The attached markup.xml parses. Instead of the "previous_uuid" error, > coils-parse-bmpl returns what I think is a JSON representation of a > Route. Yes, that tool 'compiles' the route to a Python representation of the route using the same calls as the engine. So if that can parse the markup then the markup should be installable. > That Route is more complex than the basic sample given in WMOGAG. > I'll try to trim it down to the bare necessity of what I need, and see > if I can get it to work. I'll have to look at WMOGAG, but that may just be a snippet of the route and not the entire markup [which doesn't fit easily on a printed page]. I do have the advantage that I have pre-existing BPML files [from our use of the BIE project]. This is one reason we really need a designer, or at least MKCOL support which will generate a new 'empty' route markup to which eventAction stanzas can be added. Doing that is pretty simple except for dealing with route-renames [another feature that would be nice]. Getting of the ground with editing BPML directly is clearly a significant barrier to entry. Aside - I refer to the 'compiled' markup as CPM [Coils Pickle Markup] in case you see that acronym in the code or docs somewhere. Whenever you save/install markup on the server the markup is saved AS IS [comments, whitespace, etc....] to facilitate manual editing. But at the point of save the markup is compiled to CPM in order to check the validity of the process and the CPM is what is actually *RUN* by coils.workflow.process. A copy of the route CPM becomes the process' CPM and that is updated with the completion of every action in the process - which is what allows park and resume of processes; additional state information is saved in the process CPM as the process executes. |
|
From: Bernard D. <bdr...@gm...> - 2013-02-10 20:10:49
|
On Fri, Feb 8, 2013 at 8:11 PM, Adam Tauno Williams <awi...@wh...>wrote: > > Hmmm. I wonder if cut-n-paste screws up the markup somehow. > > But I've attached one that does compile with coils-parse-bpml. You'll > need to adjust it of course. But try compiling this one. > Thanks. I had wondered if it was a problem with some invisible but extraneous characters in the xml taken from the PDF file. However, I'd opened the PDF on the same platform where I was doing the test, so one would hope that such problems would have been mitigaged, but the sample xml still would not parse. The attached markup.xml parses. Instead of the "previous_uuid" error, coils-parse-bmpl returns what I think is a JSON representation of a Route. That Route is more complex than the basic sample given in WMOGAG. I'll try to trim it down to the bare necessity of what I need, and see if I can get it to work. Regards, Bernard |
|
From: Adam T. W. <awi...@wh...> - 2013-02-08 20:11:33
|
On Fri, 2013-02-08 at 14:11 +0000, Bernard Devlin wrote: > On Fri, Feb 8, 2013 at 1:56 PM, Adam Tauno Williams > <awi...@wh...> wrote: > If you test the markup using the coils-parse-bpml tool, does > that say > the markup is OK? > > coils-parse-bpml --filename=markup.bpml > > [the tool should install from the egg, either that or it is in > the /tools folder in a checkout] > > /usr/bin/coils-parse-bpml --filename=markup.bpml > > gives this error: > > Compilation of markup failed. > BPMLSAXHandler instance has no attribute 'previous_uuid' > > > I get that error using the sample markup from WMOGAG too. Hmmm. I wonder if cut-n-paste screws up the markup somehow. But I've attached one that does compile with coils-parse-bpml. You'll need to adjust it of course. But try compiling this one. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Bernard D. <bdr...@gm...> - 2013-02-08 14:11:08
|
On Fri, Feb 8, 2013 at 1:56 PM, Adam Tauno Williams <awi...@wh...>wrote: > If you test the markup using the coils-parse-bpml tool, does that say > the markup is OK? > > coils-parse-bpml --filename=markup.bpml > > [the tool should install from the egg, either that or it is in > the /tools folder in a checkout] > /usr/bin/coils-parse-bpml --filename=markup.bpml gives this error: Compilation of markup failed. BPMLSAXHandler instance has no attribute 'previous_uuid' I get that error using the sample markup from WMOGAG too. Regards, Bernard |
|
From: Adam T. W. <awi...@wh...> - 2013-02-08 13:56:53
|
On Fri, 2013-02-08 at 13:02 +0000, Bernard Devlin wrote > I still I get the same error PUTting to a resource (even when using > the sample BPML from WMOGAG). > curl -v -u admin:pass -T markup.bpml > http://192.168.56.201:9090/dav/Workflow/Routes/markup.bpml awilliam@linux-nysu:~> curl -u awilliam:fred123 -T markup.bpml http://127.0.0.1:8080/dav/Workflow/Routes/markup.bpml Server response: linux-nysu.site - - [08/Feb/2013 13:51:26] "PUT /dav/Workflow/Routes/markup.bpml HTTP/1.1" 301 - > < HTTP/1.1 500 Error > < Server: BaseHTTP/0.3 Python/2.6.8 > < Date: Fri, 08 Feb 2013 12:24:08 GMT > < Content-Length: 38 > < Content-Type: text/plain > < Connection: close > Closing connection #0 > global name '_filename' is not defined > The content-length above is for the sample from WMOGAG, and it is an > appropriately smaller content-length if I PUT a different markup file. > Doing a GET on http://192.168.56.201:9090/dav/Workflow/Routes/.ls > returns a 200 OK and an empty JSON list, so it is not a problem with a > server path. If you test the markup using the coils-parse-bpml tool, does that say the markup is OK? coils-parse-bpml --filename=markup.bpml [the tool should install from the egg, either that or it is in the /tools folder in a checkout] -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Bernard D. <bdr...@gm...> - 2013-02-08 13:02:39
|
On Fri, Feb 8, 2013 at 10:14 AM, Adam Tauno Williams <awi...@wh... > wrote: > Yes, because that is not a legal PUT operation. You must PUT to a > resource, the above is trying to PUT a collection [your URL ends in "/". > > Do: > curl -v -u admin:pass -T markup.bpml > http://192.168.56.201:9090/dav/Workflow/Routes/markup.bpml > > If your markup is legit you should get a 301 [Moved] response. A > collection then exists which is your workflow route. > > I still I get the same error PUTting to a resource (even when using the sample BPML from WMOGAG). curl -v -u admin:pass -T markup.bpml http://192.168.56.201:9090/dav/Workflow/Routes/markup.bpml returns > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: 192.168.56.201:9090 > Accept: */* > Content-Length: 1439 > Expect: 100-continue > < HTTP/1.1 500 Error < Server: BaseHTTP/0.3 Python/2.6.8 < Date: Fri, 08 Feb 2013 12:24:08 GMT < Content-Length: 38 < Content-Type: text/plain < Connection: close Closing connection #0 global name '_filename' is not defined The content-length above is for the sample from WMOGAG, and it is an appropriately smaller content-length if I PUT a different markup file. Doing a GET on http://192.168.56.201:9090/dav/Workflow/Routes/.ls returns a 200 OK and an empty JSON list, so it is not a problem with a server path. Regards, Bernard |
|
From: Adam T. W. <awi...@wh...> - 2013-02-08 10:14:45
|
On Fri, 2013-02-08 at 01:46 +0000, Bernard Devlin wrote: > Here's the curl command I am using: > curl -v -u admin:pass -T markup.bpml > http://192.168.56.201:9090/dav/Workflow/Routes/ > There appears to be an error at line 75 of > OpenGroupware-0.1.49rc19-py2. > 6.egg/coils/protocol/dav/workflow/utility.py , where the variable > "_file" is referred to as "_filename". Yes, because that is not a legal PUT operation. You must PUT to a resource, the above is trying to PUT a collection [your URL ends in "/". Do: curl -v -u admin:pass -T markup.bpml http://192.168.56.201:9090/dav/Workflow/Routes/markup.bpml If your markup is legit you should get a 301 [Moved] response. A collection then exists which is your workflow route. |
|
From: Bernard D. <bdr...@gm...> - 2013-02-08 01:46:21
|
On Mon, Feb 4, 2013 at 2:03 PM, Adam Tauno Williams <awi...@wh...>wrote: > Currently, and for a long time, you just PUT the markup [the file] > into /dav/Workflow/Routes, and you will receive a 301 response. This > processes the contents of the markup file and creates the route - > creating a folder named after the route. > > Then you PUT data into the route's folder > [/dav/Workflow/Routes/myRoute/] and a Process will be created of that > Route. > In trying to use cadaver to PUT the route file markup.bpml to the path /dav/Workflow/Routes I was getting an error: global name '_filename' is not defined Here's the curl command I am using: curl -v -u admin:pass -T markup.bpml http://192.168.56.201:9090/dav/Workflow/Routes/ There appears to be an error at line 75 of OpenGroupware-0.1.49rc19-py2. 6.egg/coils/protocol/dav/workflow/utility.py , where the variable "_file" is referred to as "_filename". However, altering that I then get this error on PUTting the bpml file: ERROR:pathobject.Routes:BPMLSAXHandler instance has no attribute 'previous_uuid' If I try to parse the BMPL using: /usr/bin/coils-parse-bpml --filename=markup.bpml I get a similar error: Compilation of markup failed. BPMLSAXHandler instance has no attribute 'previous_uuid' That indicates I have something wrong with my markup.bpml file. My markup is basically a stripped-down version of the updateUsersFromLDAPAction xml which occurs in the WMOGAG book (p.358) If I copy the exact Route spec from the WMOGAG book, and try to use that, it too fails with this "previous_uuid" error. (I'd expect it to parse then fail subsequently, not least because it is pointing to an unavailable DSA). Regards, Bernard |
|
From: Adam T. W. <awi...@wh...> - 2013-02-04 16:44:38
|
On Mon, 2013-02-04 at 11:12 -0500, Adam Tauno Williams wrote:
> > When you get time, if you can flesh out a rough spec of the range of
> > functionality that is needed, then I can let you know if that would be
> > something I could provide.
Workflow UI is partly straight forward.
1. List of Routes
- Properties of the route
- Processes existing of that route
- Perhaps some statistics: frequency, failures, completions
- Create a process (upload / form)
2. List of Processes
- Mine vs. All Visible
- Process log & messages
3. Possibly -
- Ability to at least list / upload / delete
- Tables
- Formats
- Templates
- Editing would be nice, but that could be performed externally.
But everything that is external raises the barrier to entry to novice
users.
I create a Wiki page and attached a few screenshots to it @
<https://sourceforge.net/p/coils/wiki/WorkflowUI/> These screenshots
are from a simplistic internal OIE interface that exists in my
employer's intranet. But it doesn't really help in the creating of
anything Open Source or portable.
--
Adam Tauno Williams GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA
|
|
From: Adam T. W. <awi...@wh...> - 2013-02-04 16:21:25
|
On Mon, 2013-02-04 at 11:12 -0500, Adam Tauno Williams wrote: > > When you get time, if you can flesh out a rough spec of the range of > > functionality that is needed, then I can let you know if that would be > > something I could provide. The GUI toolset I use is currently looking > > to go entirely open-source. > There is also the Snurtle CLI, which just needs polish and some better > documentation - and probably a few BLOG posts. Snurtle <http://sourceforge.net/p/snurtle/home/Home/> is useful, but not intuitive. It currently supports most Workflow related stuff. It just really needs some polish. Adding route creation and deletion support should be straight forward; both those actions can be performed via the zOGI API already [so the server part is done]. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Adam T. W. <awi...@wh...> - 2013-02-04 16:18:33
|
On Mon, 2013-02-04 at 11:12 -0500, Adam Tauno Williams wrote: > On Mon, 2013-02-04 at 15:15 +0000, Bernard Devlin wrote: > > When you get time, if you can flesh out a rough spec of the range of > > functionality that is needed, then I can let you know if that would be > > something I could provide. The GUI toolset I use is currently looking > > to go entirely open-source. > At some point I'll probably begin hacking on the/a Gtk client again. I > am more familiar with fat-client tech; and personally I like > fat-clients. There is Imbolc <http://sourceforge.net/projects/imbolc/> This is a Python/Gtk app. It was/is very nearly functional. But was really focused on Task management [which is certainly important, and what I spend a good time each day doing]. It needs to be ported to Gtk3 / PyGobject and off of pygtk. This shouldn't be too hard. It really needs a better sync-scheme than it currently has. But I rather like the UI; it is quite powerful for filtering and sorting. It could certainly be extended to more than just Tasks - provided it gets a better sync-scheme. I'm made a couple attempts at improving it but by myself haven't had the time to work on both it an the server. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Adam T. W. <awi...@wh...> - 2013-02-04 16:12:44
|
On Mon, 2013-02-04 at 15:15 +0000, Bernard Devlin wrote: > I might be able to oblige on that front. Excellent. > What do you envisage to be the needs in terms of a UI? I'm open to ideas. There could be one or several. There could be a unified interface to all the functionality or an interface specific to the Workflow / OIE part of Coils. I'm really undecided about the way to go with that. > When you get time, if you can flesh out a rough spec of the range of > functionality that is needed, then I can let you know if that would be > something I could provide. The GUI toolset I use is currently looking > to go entirely open-source. A web interface would be nice, but I'm not a web developer [or not a Web-UI developer]. I've tried my hand at a couple but one really need to *know* Javascript to produce anything likable. At some point I'll probably begin hacking on the/a Gtk client again. I am more familiar with fat-client tech; and personally I like fat-clients. There is also the Snurtle CLI, which just needs polish and some better documentation - and probably a few BLOG posts. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Bernard D. <bdr...@gm...> - 2013-02-04 15:15:48
|
I might be able to oblige on that front. What do you envisage to be the needs in terms of a UI? When you get time, if you can flesh out a rough spec of the range of functionality that is needed, then I can let you know if that would be something I could provide. The GUI toolset I use is currently looking to go entirely open-source. Bernard On Mon, Feb 4, 2013 at 2:05 PM, Adam Tauno Williams <awi...@wh...>wrote: > > > We really need a proper user-interface for that; but sadly we lack a > front-end/UI person. > |
|
From: Adam T. W. <awi...@wh...> - 2013-02-04 14:06:05
|
On Mon, 2013-02-04 at 13:42 +0000, Bernard Devlin wrote: > Perhaps I have misunderstood how one initiates OIE Processes. Either > that or I have misconfigured my Coils installation. That would be correct for iniating a Process [putting a file into the route folder], but creating a Route is performed by putting a markup file into the Routes folder. The collection should be created automatically. We really need a proper user-interface for that; but sadly we lack a front-end/UI person. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Adam T. W. <awi...@wh...> - 2013-02-04 14:03:39
|
On Mon, 2013-02-04 at 13:42 +0000, Bernard Devlin wrote: > I've been looking into syncing an OpenLDAP directory with the > opengroupware database for accounts. > I've based the xml/bpml for the sync action off that used in the > WMOGAG guide (0.1.49rc3). My Coils installation is: 0.1.49rc19. > If I use cadaver to log into the webdav interface of the coils server > (as the OGO admin user), and navigate to the following path: > http://localhost:9090/dav/Workflow/Routes to create a folder to > contain the route's BMPL file, I get a http 500 error when using > MKCOL. > I see there is an open bug related to this (# 97). Does that mean > that this MKCOL has not yet been implemented for Workflow objects, or > does it mean that it is how one names/identifies the route that is the > problem? Correct, MKCOL is not implemented. This is due to the fact that clients are weird about how they do MKCOL. Many create a folder like "Untitled Folder" and then rename it [MOVE]. That means the route entity, and most importantly the markup, must be renamed and reprocessed. That is a PITA. Currently, and for a long time, you just PUT the markup [the file] into /dav/Workflow/Routes, and you will receive a 301 response. This processes the contents of the markup file and creates the route - creating a folder named after the route. Then you PUT data into the route's folder [/dav/Workflow/Routes/myRoute/] and a Process will be created of that Route. Perhaps it is explained poorly. Or I should just make a video. :) -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA |
|
From: Bernard D. <bdr...@gm...> - 2013-02-04 13:42:33
|
I've been looking into syncing an OpenLDAP directory with the opengroupware
database for accounts.
I've based the xml/bpml for the sync action off that used in the WMOGAG
guide (0.1.49rc3). My Coils installation is: 0.1.49rc19.
If I use cadaver to log into the webdav interface of the coils server (as
the OGO admin user), and navigate to the following path:
http://localhost:9090/dav/Workflow/Routes to create a folder to contain the
route's BMPL file, I get a http 500 error when using MKCOL.
------------------------------
INFO:authenticator:Trusted Host authentication as "ogoroot"
(objectId#10000) from remote "127.0.0.1" approved.
DEBUG:http:Selected <coils.protocol.dav.workflow.routesfolder.RoutesFolder
object at 0x9f9d76c> as handler
ERROR:http:MKCOL method not implemented on this object
Traceback (most recent call last):
File
"/usr/lib/python2.6/site-packages/OpenGroupware-0.1.49rc19-py2.6.egg/coils/net/handler.py",
line 161, in process_request
getattr(handler, 'do_{0}'.format(self.command))(self.request_name)
File
"/usr/lib/python2.6/site-packages/OpenGroupware-0.1.49rc19-py2.6.egg/coils/net/foundation/pathobject.py",
line 104, in do_MKCOL
raise CoilsException('MKCOL method not implemented on this object')
CoilsException: MKCOL method not implemented on this object
------------------------------
I took it from slide 13 of the GRPUG presentation, that the first step to
using an OIE action was to create a folder under Workflow/Routes which
would contain the Route spec and its associated files/folders:
http://www.opengroupware.us/2012/11/grpug-presentation-on-oie.html
Perhaps I have misunderstood how one initiates OIE Processes. Either that
or I have misconfigured my Coils installation.
I see there is an open bug related to this (# 97). Does that mean that
this MKCOL has not yet been implemented for Workflow objects, or does it
mean that it is how one names/identifies the route that is the problem?
Regards, Bernard
|
6 messages has been excluded from this view by a project administrator.
