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.

Mounting Via WebDAV From Windows

As of Windows XP the Microsoft Filesystem Redirector, by default, only supports DIGEST authentication.  To utilize a WebDAV server using BASIC authentication the support has to be enabled via a registry key.  The WebDAV client is configured via keys in the system hive at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters".  Create a DWORD key named "UseBasicAuth" with a value of 0, 1, or 2.

• 0 - Basic authentication disabled, this is equivalent to the default if the UseBasicAuth key is not  set.
• 1 - Basic authentication is allowed for WebDAV provided that the connection is protected by SSL/TLS.
• 2 - Basic authentication is allowed for WebDAV regardless if the connection is protected.

 A value of "1" is recommended for any type of production network;  for debugging and development purporses "2" is useful as unprotected connection can be watched with any packet capture tool such as WireShark.  Only allow unprotected connections if you are comfortable with them being seen by any third party [seeing includes both the username and password].  Attempting to mount a volume from a server using BASIC authentication that does not match the requirements set by "UseBasicAuth" will generally result in a "System Error 67".
Regardless of how user enters their credentials when prompted Windows will send a username qualified by the NetBIOS domain of either the current machine or the current domain.  If your OpenGroupware Coils server does not use an authentication scheme where qualified names are recognized you can set the StripAuthenticationDomain server default;  with that default enabled the server still strip the NetBIOS domain from the from the beginning of any login credentials before authentication is attempted.  However that operation also means that any usernames containing a "\" character will fail to authenticate.

coils-server-config --directive=StripAuthenticationDomain --value=YES

Mounting OpenGroupware Coils as drive X:

Typically if your attempts to authenticate fail with a Windows "System Error 5 has occurred" it related to sending qualified usernames to a server that expects unqualified usernames.
With BASIC authentication enabled and automatically unqualifying usernames it should be possible to mount your OpenGroupware Coils' WebDAV presentation on a Windows Workstation.
More technical information for either using the Microsoft Windows Filesystem Redirector or OpenGroupware Coils authentication options can be found at the Wiki of the SourceForge project.