A Simple Request To Print Feature

Support has been merged into the default branch for IPP [printing] operations.  This functionality will be available in 0.1.49 provided the "pycups" modules is installed on the host(s).
The first part of IPP support is the addition of a workflow acction printToIPPAction.  With the printToIPPAction a workflow message can be queued to a specified queue on an IPP server.  An advantage of IPP over LPR [which OIE has supported for some time via the printToLPRAction] is that most IPP servers can deal intelligently with various content types.  For exampe PDF, JPEG, and PNG content can usually be spooled as a print job without any client-side processing.  The printToIPPAction supports setting the media size (default is "Letter") and specifying the fit-to-page feature supported by most IPP servers.  In conjunction with capturing e-mail attachments or generating documents using RML the capability to spool messages to print queues allows the automation of processes which require hard-copy documents.
The second part of IPP support is the "/ippprint" HTTP protocol bundle.  Using the "/ippprint" protocol HTTP clients can discover a list of available printers as well as request documents be queued to a specified print queue. 
To retrieve a list of available printers a GET request for "/ippprint/.ls" is performed, this returns a JSON encoded dictionary of the print available print queues.  Keys are queue names and the referenced dictionary is a standard IPP printer queue definition.

{ "dc": { "printer-is-shared": true,
          "printer-info": "dc",
          "printer-state-message": "Ready to print.",
          "printer-type": 8433756,
          "printer-make-and-model": "Brother MFC-9840CDW BR-Script3", 
          "printer-state-reasons": ["none"],
          "printer-uri-supported": "ipp://ipp.example.com:631/printers/dc",
          "printer-state": 3,
          "printer-location": "",
          "device-uri": "ipp://ip6B43FF.example.com"},
  "hp": { "printer-is-shared": true,
          "printer-info": "HP Laser Printer",
          ....

Example JSON report of available printers.

Requesting a document id be printed to a specified queue is performed in a similar manner: "/ippprint/queue/objectid?mediasize=Letter&fittopage" where "queue" is the name of the print queue and "objectid" is the OpenGroupware object id of the document.  Read access to a document is required in order for request the document be printed.  Output size can be specified via the "mediasize" parameter and the "fitopage" option is also available.  If a media size is not specified the default is "Letter" - note that, especially with PDFs, some documents may specify a media size internally which if not overridden can pause a printer if that media size is not physically available [this behavior is determined by the configuration of the IPP server and the printer itself - OpenGrouwpare Coils has no control over that aspect of printer operation].
The printer server used by OpenGroupware is set by the "DefaultIPPServer" server default; if not provided a value of "127.0.0.1" will be assumed - an IPP service on the same host.

coils-server-config --directive=DefaultIPPServer --value=ipp.example.com
Change the server's configuration to use the IPP service provided by ipp.example.com.  The specifed IPP server must be reachable by the OpenGrouwpare Coils node which is providing HTTP services; check your firewalls.

Unfortunately most IPP servers can only automatically process common [at least quasi-] Open file types such as PDF and PNG/JPEG images.  For this reason the /ippprint protocol applies a filter, based on MIME type, for the types of documents it will allow to be queued.  When a document is requested to be queued via /ippprint the type of that document will be compared to the list of MIME types found in the server's IPPPrintableMIMETypes default.  If not configured the value of IPPPrintableMIMETypes is [ "application/pdf", "image/jpeg", "image/png" ].  This type list can be overwritten using coils-server-config to match the capabilities of your IPP service.  Should an HTTP client request a document be queued whose MIME type is not specified in IPPPrintableMIMETypes a NotSupportedException will be raised (HTTP result code 501).  A successful queue request will result in a text/plain HTTP 200 response containing the job name of the queued job [/ippprint will generate a job name and provide it to the IPP service].
With IPP queuing support simple HTTP clients are still oblivious to the document types that can be successfully queued for printing.  Making a request and checking the result code is the only reliable way to 'discover' the print-ability of a document.  In order to make this more intuitive for users, and easier for the generally very lazy web developer, a new "IPPPRINTABLE" flag is now included in the FLAGS attribute of the Omphalos representation of a document. 

{'FLAGS': ['WRITE', 'OWNER', 'IPPPRINTABLE'],
 'creation': ,
 'creatorObjectId': 10000,
 'entityName': 'File',
 'fileSize': 90566,
 'fileType': 'pdf',
 'filename': 'BasicManagementOfEFIBootLoaders',
 'folderObjectId': 10160,
 'lastModified': ,
 'mimetype': 'application/pdf',
 'objectId': 289850,
 'ownerObjectId': 10000,
 'projectObjectId': 10140,
 'status': 'inserted',
 'title': 'BasicManagementOfEFIBootLoaders.pdf',
 'version': 1}
Omphalos representation of a File [Document] having the "IPPPRINTABLE" flag due the MIME type of the file's contents.

By simply checking for this flag HTTP clients retrieving document lists via XML-RPC, JSON-RPC, or ".ls" requests to WebDAV can toggle on and off the availability of any request-to-print feature.
Request to print via HTTP can provide an easier path to producing hard-copy over downloading the document to the client, opening it [hopefully] in an appropriate application, and then printing it to a printer that must be configured on the client (and potentially selected by the user).

Collection Creation

Many things are "collections";  projects are collections, document folders are collections, in OpenGrouwpare Coils even "Collections" are collections!  A frequent action is the creation of a new collection - and there are lots of ways to do it.  Most obviously a collection can be created interactively using a WebDAV client such as Nautilus (which accesses GVFS's WebDAV support), the Microsoft Windows WebDAV Redirector, Cyberduck, cadaver, WebDAV Nav Lite for Android or IOS, etc... 
All these WebDAV clients create collections by making an HTTP MKCOL requests.  With MKCOL requests it is all a matter of "where". If you create a collection in "/dav/Projects" you are creating a new project (which is a collection).  If you create a collection in a documents folder then you are creating a new sub-folder (which is a collection).  If you create a collection in "/dav/Contacts" then you are creating a new address book (which is a collection).  HTTP MKCOL operations are very simple - make a MKCOL request for the collection you need to exist.  And then it exists.  So if interactive clients are not your thing or you need to automate some collection creation you can do it from the command line using a standard HTTP utility such as curl:

curl -u $LOGNAME -X MKCOL \
  http://coils.example.com/dav/Projects/test123/Documents/georgeMaking a new subfolder named "george" in the document hierarchy of project "test123"

curl -u $LOGNAME -X MKCOL \
  http://coils.example.com/dav/Projects/newprojectCreate a new project identified as "newproject".

If a project is deep within a project hierarchy a useful trick is that you can always navigate to a project from "/dav/Projects/number" if you know the number of the project - project numbers are unique, so this is always safe.  This simplifies the creation of document sub-folders, or sub-projects, in projects that are in a project hierarchy [it avoids the tedium of having to construct the entire hierarchy].  For example if I want to create a document folder named "stanley" in "project3" which is a child of "project2" which is itself a child of "project1" I would be dealing with a complete WebDAV path like "/dav/Projects/project1/Projects/project2/Projects/project3/Documents/stanley".  Oy!  That is just fine for navigating in a file-manager (where I can create bookmarks and shortcuts) but not much fun for the developer. The alternative is to ignore the hierarchy as presented to clients and use the project number shortcut.

curl -u $LOGNAME -X MKCOL http://coils.example.com/dav/Projects/top3-1/Documents/stanley

As project "project3" is a child project a WebDAV client will not see it at the top of the hierarchy - but it is still addressable there by making an explicit request.
Alternatively project, folder, and collection objects can be created by using the zOGI API via XML-RPC or JSON-RPC.  A call to zogi.putObject can create any of the aforementioned collection types [actually it can create just about any object type, collection or not].

import xmlrpclib
server = xmlrpclib.ServerProxy('http://coils.example.com/RPC2')
server.zogi.putObject( { 'entityName': 'Folder',
                                       'parentObjectid': 1234567
                                       'title': 'stanley' }Create a new subfolder of the folder with objectId 1234567 named "stanley" via zOGI over XML-RPC.

zOGI over JSON-RPC is what is used by the snurtle client.  In the development version of snurtle it is now possible to select a project and then navigate around within its document hierarchy creating subfolders, deleting objects, etc...  And with the availability of the zOGI API snurtle allows you to view and modify the ACLs and properties of those objects as well (operations that are rarely supported by WebDAV clients).

adam>select-project --objectid=81203049
adam:Equipment:/>mkdir incoming
adam:Equipment:/>cd incoming
adam:Equipment:incoming>cd incoming
adam:Equipment:incoming>mkdir invoices
adam:Equipment:incoming>mkdir receipts
adam:Equipment:incoming>mkdir warranties
adam:Equipment:incoming>ls
  + 88930399   invoices
  + 88930419   receipts
  + 88930439   warrantiesadam:C-Tabs:incoming>set-acl --objectid=88930399 --contextid=8999 --read --write
adam:C-Tabs:incoming>set-acl --objectid=88930419 --contextid=8999 --read --write
adam:C-Tabs:incoming>set-acl --objectid=88930439 --contextid=8999 --read --write
adam:C-Tabs:incoming>set-property --objectid=88930399 --namespace=http://www.opengroupware.us/smtp --attribute=collectMIMEType --value=application/pdf
adam:C-Tabs:incoming>set-property --objectid=88930419 --namespace=http://www.opengroupware.us/smtp --attribute=collectMIMEType -alue=application/pdf
adam:C-Tabs:incoming>set-property --objectid=88930439 --namespace=http://www.opengroupware.us/smtp --attribute=collectMIMEType --value=application/pdf
adam:C-Tabs:incoming>list-properties --objectid=88930399
{http://www.opengroupware.us/smtp}collectMIMEType = application/pdf
adam:C-Tabs:incoming>list-acls --objectid=88930399
  ACL (Contact, 8999) = (allowed, wr)
Select a project and create some sub-folders that can receive PDF documents via SMTP from document scanners.

Starting & Stopping Process Invocation

When running the coils.workflow.manager is constantly trolling for queued processes that are ready to run.  On the other hand the System Administrator needs to perform some maintenance and needs the system quiescent.... what to do?  Use the coils-workflow-control tool.  This tool [command] can be used on any node in an OpenGroupware Coils cluster to change the state of the coils.workflow.manager component.

coils-workflow-control --disable
coils-workflow-control --enable
coils-workflow-control --scan

Options

• --disable : Disables the coils.workflow.manager component's starting of queued processes.  When disabled no new processes will be started.  Processes may still be created and queued, but execution will not commence.  Currently running processes will not be stopped, but no further processes will start.  It is 'safe' to kill the engine once no processes are running and the manager is in a disabled state.  NOTE: Currently the coils.workflow.manager component will always start in an enabled state even if it was disabled when shutdown - but it always waits approximately three minutes after start-up before starting any processes.
• --enable : Enables the coils.workflow.manager component's starting of queued processes.  This just undoes a --disable request.  Enabling an already enabled engine has no effect.
• --scan : Request that the coils.workflow.manager component immediately check its process queue for available processes.  Normally there is no reason to use --scan as the component performs this check whenever a running process completes or fails, a new process is queued (via WebDAV for example) as well as at regular intervals.

If the Python module procname is installed on the workflow host processes will change their OS process name to contain the OpenGroupware Coils Process Id - with just this tool and regular sys-admin tools like "top" it is simple to monitor and control the execution of workflow processes.

OpenGroupware Coils 0.1.49rc33 Released

OpenGroupware Coils 0.1.49rc33 has been uploaded to SourceForge and PyPI.  There are a large number of improvements, enhancements, and bug-fixes.  At this point all the requirements for 0.1.49 final exist in the patch queue; it is just a matter of doing review and documentation.  I anticipate one more rc release until 0.1.49, and then onto defining the milestones for 0.1.50.

• A documents extension and abstract values are exposes as eponymous WebDAV properties in the Coils' namespace.
• A document's abstract can be set/updated via WebDAV PROPPATCH
• ENHANCEMENT: Allow mime-type of getObjectPropertyAction to be set via parameter, and allow for defaults if the property does not exist.
• Several additional label substitution values: INITDATE, WEEKAGO, FORTNIGHTAGO, and MONTHAGO.
• New sshDeleteFiles OIE action; allows deletion of remote via via SFTP.
• AttachFS support for update of document's by object id. A full set of AttachFS examples is now available in the project wiki.
• FLAGS implemented on the Omphalos representation of Project entities.
• Omphalos Project representations include parentProjectName and parentProjectNumber attributes if the Project has a parent. This facilitates the create of client interfaces representing project hierarchies.
• At a detail level of 1,024 Omphalos representations of a Project includes a childProjectObjectIds attribute which is an array of child project object ids.
• A parent / children relation has been added to the SQLAlchemy ORM for Project entities.
• System Administrators and Workflow Administrators can now delete any Route entity regardless of ownership or permissions.
• Provisioning scheme for resource objects in Project 7,000 is now complete.
• Many improvements to the Wiki protocol bundle:
• Wiki support for serving JavaScript resources.
• Wiki now provides a CSS resource for styling, this is automatically created in Project 7,000 by the coils-fix-provision7000 tool.
• Wiki Query Tables now return more than the default 150 search results.
• A 'root' Wiki document is now provisioned in Project 7,0000 by the coils-fix-provision7000 tool.
• Wiki supports entity relative links "." and ".." for project and folder links.
• Markdown "TOC" (Table of Contents) extensions enabled in the Wiki bundle.
• A user-agent has been defined for the WebDAV client cadaver. Includes work-around for escaped/unescaped hrefs issue.
• assignment entities may now be putObject'd and deleteObject'd in the zOGI API (this was a blocker for 0.1.49 final).
• team::delete Logic command now supports deletion by objectId. Only system administrators may delete teams. 
• Team entitues may now be created via zOGI putObject (this was a blocker for 0.1.49 final).
• Implementation of the HTTP redirector protocol at /redirect or /r. Redirector map is provisioned in Project 7,0000 by coils-fix-provision7000.
• Document project id, company id, and folder id are now exposed as WebDAV properties.
• New OIE actions setObjectPropertyAction and getObjectPropertyAction.
• The object property "{http://www.opengroupware.us/oie}disableStateVersioning" on an OIE process will disable state versioning for that process. This discards some, rarely useful, auditing information in exchange for a reductuion in I/O.
• BUGFIX in OIE xPathAction relating to XML having no support for default namespaces in XPath statements.
• OIE Processes now inherit copies of a Route's object properties upon creation.
• BUGFIX in OIE ldapSearchAction which could cause large LDAP search results to be incorrected paged, and thus truncated.
• BUGFIX in coils-fix-clean-message-folder tool where the tool failed on some versions of Python.
• BUGFIX when using a divisor to read a floating-point value via SimpleFixedFieldFormat.
• SMTP listener can now deliver content to Project folders.
• OIE xlsToXmlAction now renders all element names in lower case.

Coils Specific Properties via WebDAV

WebDAV clients operate in the server's folder and document hierarchy.  This is a convenient and powerful way to approach and manipulate the server's data - but it does obscure a significant amount of information as well.  For example a document in WebDAV is known by it's filename [and perhaps its displayName as well, depending on the client].  But the object id is unavailable, as is the object id of the folder containing the document, the SHA-512 checksum, and a variety of other attributes.  Particularly when learning the server's data model or developing clients it can be useful to explore both the WebDAV presentation as well as the other available attributes.  Most WebDAV clients provide no means to access server-specific values, but fortunately the cross platform WebDAV utility cadaver provides exactly this. With cadaver the user or developer can easily query the value of attributes in alternative namespaces.
The OpenGroupware Coils' WebDAV presentation makes a variety of useful object attributes available as properties through its namespace [57c7fc84-3cea-417d-af54-b659eb87a046].  The "set namespace" command in cadaver is used to determine the namespace for subsequent property queries. With the namespace set the propget command is used to retrieve the value of a named property, for example: "propget filename.txt objectid" will retrieve of value of the object id property of the named object.

Retrieve a variety of OpenGroupware Coils specific attributes for a document object.

The ability to set an arbitrary namespace for the property query means the feature is not limited to asking for OpenGroupware Coils specific attributes; it is possible to query for attributes defined by the various specifications [CalDAV, CardDAV, GroupDAV, etc...] or for other vendor specific properties like those used to emulate Microsoft file attributes.
In addition to simply querying properties cadaver also provides for deleting and setting mutable properties, and for locking objects and querying objects for existing locks.  It is an indispensable tool for the WebDAV developer.
cadaver is packaged in the main repositories of all major LINUX distributions, can be built for Mac OS/X, and runs on Microsoft Windows via Cygwin.

AttachFS PUT to Projects and Tasks

AttachFS allows operations to be performed on BLOB content using simple HTTP operations such as GET and PUT, without much of the complexity [or the features!] of WebDAV. Most significantly AttachFS allows BLOBs to be manipulated by id rather than path – a simpler approach for a variety of clients and types of applictions. The ability to create and update project documents has been available since the original addition of the AttachFS presentation to the OpenGroupware Coils protocol bundles.

But for applications that may be focused on Projects and Tasks, rather than Folders and Documents, even manipulation of documents by id can require the application to keep track of additional information (such as the Folder where a document is stored) and require additional UI for interaction with the user – such as where they want a document stored. To streamline these types of operations AttachFS now allows upload [HTTP PUT] of documents directly to a Project or Task object. If the target of an upload is a Project or a Task then the AttachFS will automatically determine where to store the uploaded document as well as create object links on behalf of the client application in order to persist the relationship between the document and the targetted object.

AttachFS upload URLs remane unchanged:

/attachfs/objectId/filename

When the objectId is that of a Project object how the document will be saved to the Project is determined by a bit of server configuration. If no configuration has been performed the document is simply saved to the root folder of the project. The files are always created, or updated, using the provided filename. If a file already exists in the target folder with the provided filename than a new version of the document is created (the document is updated). The obvious downside of this approach is that the root folder of a Project can quickly become very cluttered and content uploaded in this way becomes indistinguishable from content saved deliberately to that path via a WebDAV or zOGI client.

An alternative is to set the ProjectINBOXFolderPath server default; when this default is defined it specifies a folder name to which uploaded documents will be saved, beneath the root folder of the project. For example if ProjectINBOXFolderPath is set to a value of “INBOX” then all documents uploaded to a Project via AttachFS will be created in the project folder “/INBOX”. If no folder by that name exists in a Project the server will create it the first time a document is uploaded to the project via AttachFS. This makes documents uploaded in this manner distinct from other documents and avoids cluttering the Projects's root folder. Users, client applications, or workflows can then relocate and rename these documents. Additionally a per-project path can be specified using an object property created on the Project; if set this will override any value provided by the ProjectINBOXFolderPath server default. The object property is “inboxPath” in the “57c7fc84-3cea-417d-af54-b659eb87a046” namespace. The value may be any string which is a legal Folder name.

adam> set-property –objectid=1234567 --namespace=57c7fc84-3cea-417d-af54-b659eb87a046 –attribute=inboxPath –value=MyProjectsINBOXFolder
Setting the INBOX folder name on Project OGo#1234567

If an upload folder is specified by server default the functionality can also be disabled by setting this object property's value to indicate the project's root folder [“/”].

Redirected uploads, such as uploading a document to a Project via an associated Task, provide an additional feature for automatic categorization. If the server default ProjectINBOXSubdirEnabled has a value of “YES” then in the target folder a subfolder will be created whose name is the object id of the object through which the document was uploaded – in the case of a Task this will be the object id of the Task, in the case of a Project the object id of the Project, etc... This feature can be enabled, or disabled, per Project by creating an object property on the Project named "useINBOXSubfolders" in the "57c7fc84-3cea-417d-af54-b659eb87a046" namespace. The value of the property should be “YES” or “NO”; existence of the property will always override the server's default, a value of “YES” enables the subfoldering feature, any other value evaluates to false and will disable the feature.

adam> set-property –objectid=1234567 --namespace=57c7fc84-3cea-417d-af54-b659eb87a046 –attribute=useINBOXSubfolders –value=YES
Enabling the use of INBOX subfolders in Project OGo#1234567

When a document is uploaded to a Task which is assigned to a Project the upload will be proxied to the associated Project and the upload will be processed as if the Project was the target of the upload. If an upload is attempted on a Task that is not assigned to Project an exception will be raised and an error returned to the client [the server has no obvious location to store the document - Documents exist in Folders and Folder hierarchies exist within Projects]. 
If completely generalized uploading of BLOB content is desired the client application can upload content as object attachments; the downside being that attachments do not exist in the server's Document hierarchy and thus cannot be accessed via the WebDAV presentation.

Regardless of INBOX or subfolder mode any document uploaded by proxying through another object such as a Project or Task, will be linked to the proxy object by an object link. The source of the link will be the object through which the upload was proxied and the target of the link will be document itself. If a Task was the target of the upload an object link will be created from the task to the uploaded Document. This persists the relationship between the object and the Document; these links will be apparent to clients using the Omphalos/zOGI representation of the object.

For example: a Task OGo#888888 is assigned to Project OGo#777777. The object properties on the Project are:

{57c7fc84-3cea-417d-af54-b659eb87a046}inboxPath = attachments

{57c7fc84-3cea-417d-af54-b659eb87a046}useINBOXSubfolders = YES

A document named "fred.txt" is uploaded to Task OGo#888888 will be saved as “/attachments/888888/fred.txt” in the Project OGo#777777. If the folder(s) do not exist they will be created automatically. If the path including the file-name already exists the contents of the document will be updated. An object link will be created from Task OGo#888888 to the new or updated Document.
A document can be uploaded to this Task using just the command like curl command:

curl -u username -T myfile.txt http://coils.example.com/attachfs/777777/fred.txt

Whatever the development or scripting environment - performing this operation is simple, which is the entire point of AttachFS.

The SMTP Listener

Similar to the coils.workflow.9100 service that can deliver raw socket connections into defined workflows OpenGroupware Coils also provides an SMTP listener.  The listener enables workflows to receive messages via SMTP; simply configure your MTA (Mail Transfer Agent) to route some prefix such as "ogo" to your OpenGroupware Coils instance and then use plussed address syntax to deliver e-mail messages to specific objects. 
Workflows can be invoked using ogo+wf+routeName@ syntax; for example to send an e-mail message to the workflow named ExampleStatusUpdate a message would be sent to ogo+wf+examplestatusupdate@example.com.  In the case of a workflow the text/plain body of the message will become the input message for a new instance (Process) of that route.  A ticket is open to implement support for receiving specific MIME-types attached to a message as the process' input message.
To target an entity with a message, assuming your delivery is routing ogo@ to the OpenGroupware Coils listener, send a message to ogo+objectId@example.com where objectId is the numeric object id of the entity.  In most cases the entity must allow read access to the NetworkContext (OGo#8999) via an ACE in the object's ACL.  OpenGroupware Coils network service components interact with the object model with the NetworkContext, this security context has minimal access to the server's objects and content for obvious security reasons.  Additional access must be deliberately granted to allow unathenticated services such as the socket and SMTP listener to interact with an object.
Document folders are one entity that supports receiving messages from the SMTP listener.  In order to access the folder the NetworkContext must have read access to the folder entity and in order to actually store content in the folder it must have write access.  For this reason it is recommended that a specific folder be created in a project for the purpose of receiving SMTP messages; from that folder a user, application, or workflow can relocate and possibly rename the documents.
For example, a message sent to ogo+1234567@example.com, where OGo#1234567 is a document folder to which NetworkContexts has read/write permissions, will be stored in its raw form in that folder.  Most document-oriented applications however cannot easily deal with raw e-mail messages [after all, they aren't e-mail clients].  Perhaps what you really need is some document that is attached to these e-mail messages?  This is a common use case with document centers - they scan documents into PDF and delivery them via SMTP.  In order to facilitate this use-case and to streamline document management the user or application can define the MIME type of the documents the folder should receive.  If a MIME type is defined for SMTP collection on a folder than only that type of document, attached to a received message, will be saved - the attachments will be automatically saved from the message and the message itself discarded.
In order to define a MIME-type for SMTP collection on a folder create an object property in the "http://www.opengroupware.us/smtp" namespace having an attribute name of "collectMIMEType".  The value of that property should be the MIME-type you desire to collection.  For example, if "{http://www.opengroupware.us/smtp}collectMIMEType" was defined on OGo#1234567 [from our previous example] having a value of "application/pdf" then only PDF attachments would saved to the folder.  There are two special-case MIME-types:

• message/rfc822 - This is the default type, and just as if the object property were not defined, will cause incoming messages to be saved in their entirety.
• text/plain - This value will save the text/plain message body as a document in the folder.

On every document created by the SMTP listener a set of object properties will be created.  These properties correspond to headers in the e-mail message from which the document was created; if a corresponding header does not exist in the e-mail message than the corresponding object property will not be created.  The SMTP listener defines a set of interesting headers;  if you believe there are headers that should be captured but are not included in this list feel free to request the addition of the header via the projects' ticket application of SourceForge.

The currently defined list of object properties created from message headers are:

• {us.opengroupware.mail.header}subject
• {us.opengroupware.mail.header}x-spam-level
• {us.opengroupware.mail.header}from
• {us.opengroupware.mail.header}to
• {us.opengroupware.mail.header}date
• {us.opengroupware.mail.header}x-spam-status
• {us.opengroupware.mail.header}reply-to
• {us.opengroupware.mail.header}x-virus-scanned
• {us.opengroupware.mail.header}x-bugzilla-classification
• {us.opengroupware.mail.header}x-bugzilla-product
• {us.opengroupware.mail.header}x-bugzilla-component
• {us.opengroupware.mail.header}x-bugzilla-severity
• {us.opengroupware.mail.header}x-bugzilla-status
• {us.opengroupware.mail.header}x-bugzilla-url
• {us.opengroupware.mail.header}x-mailer
• {us.opengroupware.mail.header}x-original-sender
• {us.opengroupware.mail.header}mailing-list
• {us.opengroupware.mail.header}list-id
• {us.opengroupware.mail.header}x-opengroupware-regarding
• {us.opengroupware.mail.header}x-opengroupware-objectid
• {us.opengroupware.mail.header}x-original-to
• {us.opengroupware.mail.header}in-reply-to
• {us.opengroupware.mail.header}cc
• {us.opengroupware.mail.header}x-gm-message-state
• {us.opengroupware.mail.header}message-id

All documents created will have at least the property "{us.opengroupware.mail.header}message-id" as Message-ID is a required header [per RFC822].  The SMTP component will not process a message that lacks a Message-ID header.  The Message-ID and a timestamp are used to create the documents filename.
In addition to these properties the property "{http://www.opengroupware.us/mswebdav}contentType" used by the WebDAV presentation will also be set on created documents to store the original MIME-type.
These properties can be used to correlate or qualify the documents, and [of course] can be used as search qualifications when using zOGI's searchForObjects.
Document creation by SMTP provides for a very simple integration path with innumerable both consumer and enterprise level devices.  From there your applications can easily access the documents by zOGI (JSON-RPC or XML-RPC), AttachFS (REST), or WebDAV.