Invitation to connect on LinkedIn

Good news for Evolution users with GroupDAV servers.

The bug to support Location headers in PUT responses has just been
closed.  This brings Evolutions WebDAV address book into compliance with
GroupDAV as specified in section 5.4.

"Handle server's resource rename on WebDAV PUT response"
<https://bugzilla.gnome.org/show_bug.cgi?id=566354>

And for more efficient synchronization support for ctags has also been
committed.

"WebDAV Addressbook backend should use ctags"
<https://bugzilla.gnome.org/show_bug.cgi?id=617168>

-- 
Adam Tauno Williams <awilliam <at> whitemice.org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

Announcing the OpenGroupware Coils project...

This message is the official public announcement of the OpenGroupware
Coils project.

**** ANNOUNCEMENT ****
OpenGroupware Coils <http://sourceforge.net/projects/coils/> is a port
of the OpenGroupware collaboration platform from SOPE & Objective-C to
Python 2.6.  It is intended to be backwards compatible and can be
installed in parallel with your existing OpenGroupware Obj-C services
stack.  OpenGroupware Coils will read you OpenGroupware Obj-C
configuration files, connect to your OpenGroupware Obj-C database, and
perform updates in a manner compatible with OpenGroupware Obj-C.
OpenGroupware Coils will maintain parallel compatibility until such time
as it reaches operational feature parity.  This is an *alpha* release of
OpenGroupware Coils and is (a) not feature complete and (b) under heavy
development.  However to commitment to parallel compatibility until
feature-parity ensures that moving between development versions will the
painless;  and you can continue to use your existing OpenGroupware
application stack.

What works today?
 1.) Reading and management of NextStep/OpenStep configuration files.
Coils can both read an write the same plist files for user defaults and
the NSGlobalDomain plist for configuration information.  So installing
OpenGroupware Coils is a zero-config process.  Although there very well
may be items you want to tweak.  Every effort is made to re-use existing
OpenGroupware defaults - which are documented in WMOGAG
<http://docs.opengroupware.org/Members/whitemice/wmogag/file_view>
 2.) The XML-RPC proxy will intercept XML-RPC calls to OpenGroupware
Obj-C's ZideStore service.  It provides retry, so if the call to
ZideStore fails [due to process restart, etc...] the call is
automatically retried.   It can also process specific API calls in Coils
while relaying others to ZideStore's zOGI bundle.  This allows a gradual
migration from ZideStore's zOGI implementation to Coil's implementation
transparent to applications.  By default the Coil's zOGI only processes
zogi.getLoginAccount calls.  This offloads most of the authentication
related calls from ZideStore to Coils.
 3.) The GroupDAV/WebDAV presentation of the contacts available to a
client has been tested in Novell Evolution successfully.  Coils has been
architected to make the presentation of large collections as efficient
as possible.  Testing is performed using an addressbook containing
22,000 contacts.  Write support is in the early stages of development.
Coils uses the Python module vobject
<http://vobject.skyhouseconsulting.com/> to process vCard data.
 3.1.) Contacts can be retrieved from the server as vCards or presented
in XML, JSON, or YAML.  Whatever is easiest for your client application
to process.
 3.2.) A special URL provides a JSON feed of contacts or users
(accounts) with upcoming birthdays.
 4.) Read support should for for CalDAV clients.  Collects are presented
that provide either the user's personal calendar or a user's Overview
calendar as determined by their panel.
 5.) Most zOGI getObject(...) operations are functional.
 6.) A large portion of the require Logic (commands) have been
implemented.  Access control has also been implemented.  Access control
in Coils offers features in addition to the OpenGroupware Obj-C services
including proxy user and negative ACLs.
 7.) The OpenGroupware Integration Engine (OIE), which not complete, is
operational and has reached a useful level of utility.  OIE provides a
workflow and Business Process Modeling engine that tightly integrates
with OpenGroupware's more traditional groupware facilities.  OIE
currently manages workflows described using BPML 1.1.  
 7.1.) Routes can be created and modified, and processes initiated and
monitored via the WebDAV presentation;  the entire workflow system can
be controlled via GNOME's Nautilus file manager and possibly other
WebDAV clients [only Nautilus/GVFS have currently been tested].  
 7.2.) OIE can perform operations with external SQL databases [tested
with IBM Informix/DB2], search LDAP DSAs [search results are
XML/DSMLv1], manipulate XML (perform XPath assignments and XSLT
transformations), convert JSON data into XML, retrieve OpenGroupware
objects as XML (such as Contacts, Enterprises, etc...), send SMTP mail
(including attachemnts), and perform various string operations and
regular expression matches.
 7.3.) OIE contains an extensible method for dealing with file formats
such as fixed record length text files, XLS, and DIF files.  File
formats can be create and defined [as YAML text] via the WebDAV layer
using a text editor such as GNOME's gedit.  File format definitions
allow OIE to read or create formatted files, such as XLS documents.
 7.4.) OIE processes can "park".  Allowing processing to stop (actually
shutting down the worker on the server) awaiting additional data or user
response,  for example, from an e-mail produced by the OIE workflow.  In
future versions OIE's processing will be integrated further with
groupware functions allowing workflows to be initiated via task
creation/completion, entity modification, etc...   
  8.) OpenGroupware Coils provides the concept of "Content Plugins".
This implements the functionality intended for the ZideStore zOGI bundle
(pluginData entity is defined for the zOGI specification:
<http://code.google.com/p/zogi/wiki/PluginData>) but deemed unrealistic
to implement in the existing Objective-C environment.  Content Plugins
allow additional information from external services (such as an ERP
system) to be gathered by OpenGroupware Coils and delivered to clients
with related entities.  For example, when an Enterprise entity is
retrieved by a zOGI call sales and related information can be added by a
custom ContentPlugin to the data that is returned to the client.
Unwitting clients can simply ignore the additional information, but
custom interfaces such as a CRM system can present the information to
use user without themselves having to contain logic to gather the
information from ERP or requiring permissions to access the ERP.  Data
made available to OpenGroupware via Content Plugins is also
automatically available to OpenGroupware Integration Engine workflows.
So you can code your connectors once and use that data from everywhere
that you can access your OpenGroupware server via HTTP.  A developer
only needs to inherit the ContentPlugin class and their content plugin
will automatically be loaded and used by OpenGroupware Coils.  An
example ContentPlugin that provides integration with Twitter has already
been implemented;  this plugin automatically includes a contact's
Twitter timeline with the contact's data.
<http://coils.hg.sourceforge.net/hgweb/coils/coils/file/db62d0ee9f9b/src/coils/logic/twitter/content_plugin.py>

Architecure:
  OpenGroupware Coils is similair in many respects to OpenGroupware
Obj-C architecturally.  Both use a Logic layer where operations are
performed using Command pattern objects.  Both divide the presentation,
operational (Logic), and model into discrete layers.  
  However OpenGroupware Coils is implemented as a component oriented
service as it is intended to provide services in addition to web
services and to really less of external OS components [such as cron].
OpenGroupware is comprised of a collection of services - one of which
provides the HTTP services - that communicate via AMQ
<http://www.amqp.org/confluence/display/AMQP/> using an AMQ server such
as RabbitMQ <http://www.rabbitmq.com/>.  AMQ provides flexible, fast,
and *reliable* messaging between components.  [This design decision was
made only after it was clearly demonstrated that RabbitMQ is readily
available for all mainstream LINUX distributions and is *VERY* simple to
install and configure - in fact, you can get Coils up and running with
RabbitMQ with *zero* MQ configuration].  One exciting possibility AMQ
provides is for future versions of OpenGroupware Coils to distribute
services across multiple hosts or multiple networks.
  Component services include HTTP services, the OpenGroupware
Integration Engine, maintenance of the Contact vCard cache, and
appointment notification.  Implementing addition services is very simple
as all the AMQ plumbing is abstracted into the Service class.  All the
developer needs to do is inherit the coils.core.Service class and
implement a few methods and the service will automatically be started
with OpenGroupware Coils and connected to the messaging service.  For an
example of how, almost trivial, it is to implement an OpenGroupware
Coils service take a look at Coils "clock"
service
<http://coils.hg.sourceforge.net/hgweb/coils/coils/file/db62d0ee9f9b/src/coils/logic/pubsub/clock.py>
which provides a clock service to which other services can subscribe to.

How can I contribute?
  All contributions and comments are welcome.  
  Non-developers can help with testing or helping to maintain the wiki.
The project also needs web-desginers and artists.
  For developers source code is managed in a Mercurial
<http://mercurial.selenic.com/> repository on SourceForge.  Mercurial is
a modern distributed source code management system, which unlike CVS and
subversion, makes managing branches and commit access a very open and
natural process.  To check out the source code go to
<http://sourceforge.net/projects/coils/develop>.  <Monodevelop
http://monodevelop.com/> solution and project files are included in the
source; so if you have that excellent, free, and multiplatform IDE
available browsing the OpenGroupware Coils source is a snap.  But use of
Monodevelop, or any IDE, is not required to contribute code to the
OpenGroupware Coils <http://sourceforge.net/projects/coils/> project.
The excellent TortoiseHg <http://tortoisehg.bitbucket.org/> tools for
working with Mercurial are also recommended - but you can do everything
via the Mercurial hg command line utility.  Every kind of work is
available within the OpenGroupware Coils project:  if you want to work
with OIE to process XML and implement workflows, if you want to work on
HTTP protocols like WebDAV/GroupDAV/CalDAV/RSS there are jobs for you,
if you want to do database oriented work via the amazing SQLalchemy ORM
<http://www.sqlalchemy.org/>, or get into the nut-n-bolts of AMQP...
just check out the code and dig in.

For communication the OpenGroupware Coils project has two mailing lists:

coils-devel for discussion of the development of the OpenGroupware Coils
project;  technical stuff.
<https://lists.sourceforge.net/lists/listinfo/coils-devel>

coils-project for discussion of the project itself including website,
coordination, promotion, etc..
<https://lists.sourceforge.net/lists/listinfo/coils-project>

OpenGroupware Coils does not *yet* have a "coils-users" yet!  This is an
*alpha* release.  A "coils-user" list will be created with the project
deliverys a 1.0 download.   The project is currently looking for
developers and other contributors.  Not that OpenGroupware Coils isn't
already very usefule - it is! - but the project wants to be very clear
about its current state and not over-sell.

Links:
* Provisioning a CentOS5 host for OpenGroupware Coils
<https://sourceforge.net/apps/trac/coils/wiki/ProvisioningCentOS5>
* Installing OpenGroupware Coils
<https://sourceforge.net/apps/trac/coils/wiki/Installation>

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

tasks access control

I think that tasks don't support acls in opengroupware, anyway, tasks 
not linked to a project are only shown in owner's (and executor's) 
webui, so that these are the only users who can view and change 
everything. This is not the case when a task is linked to a project as 
task list is shown in projects and anyone who has read access to the 
project can change everything.

Is this right? Maybe this can be changed in jobUI templates?

Many Thanks

Renzo Vettori
--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

OGO-WebUI Error column t1.birthname does not exist

Hi,

Just setup OGO 5.5 from the repository at 
http://download.opensuse.org/repositories/server://OpenGroupware/CentOS_5/ 
on a Centos system to do some testing with Zideone and I get this error 
in the browser when I first try to log in.

Application Server caught exception:

  session: 54FD54FD014ACC7724
  element: 
  context: <0x0xa464034[WOContext]: 0014acc77240a464034 app=ogo-webui-5.5 sn=54FD54FD014ACC7724
eid= rqeid=>
  request: <WORequest[0x0xa4607d4]: method=GET uri=/OpenGroupware app=OpenGroupware rqKey= rqPath=>

  class:   PostgreSQL72Exception
  name:    PostgreSQL72FatalError
  reason:  fatal pgsql error (channel=<0x0xa68b574[PostgreSQL72Channel]:
connection=<0x0xa68b75c[PGConnection]:  \
connection=0x0xa68bfb0>>): ERROR:  column t1.birthname does not exist

  info:

The same error message is in the WebUI error log.

Postgres has the OGo database installed by the .rpm. I can't see a table 
with a t1.birthname column.

I recall seeing some discussion about schema alterations but not 
involving t1.birthname as far as I recall

I noticed that the file pg-update-1.x-to-5.5.psql includes the stanza

ALTER TABLE company ADD COLUMN birthname     VARCHAR(255) NULL;



Any ideas. I've probably missed something obvious.

Thanks

Ken

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

Documentation and files on opensuse

Dear readers,

Recently I found opengroupware as  a very suitable program for me, in order to 
be able to access my mail, agenda and contacts everywhere with web access and 
clients.
On my server I use opensuse, but I found that there are (almost) no rpms 
available in the repositories for version 11.0 and 11.1 
(http://download.opensuse.org/repositories/server:/OpenGroupware/) I've worked 
around this by installing the SLE_10 rpms and they appear to work. At least, I 
get a response at localhost/OpenGroupware,  but I get a error 500. I wanted to 
check some logs, but in apache error and access logs I found nothing useful. 
From the installed files, I noticed a lot of files are installed in /usr/bin, 
/usr/lib and /usr/share/opengroupware-5.5 and 1.1 But I could not find any 
clear man pages or manual documents. The manuals on opengroupware.org are 
about a running server, but I can not find a manual on how to get a server 
running.
I hope someone can help me get ogo working on opensuse 11.x!

Thanks and with kind regards,

Vincent

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

Quick Version Question

Hi,

I'd like to test the ZideOne connector on OGo. I have an OGo 
installation done via RPM on an FC6 system.

The ZideOne connector says it prefers to work with V5.4 or 5.5

The test FC6 system claims to be have ogo-webui 1.1, xmlrpc 1.1, 
zidestore 1.5.

I'm sure the FC6 install isn't really ancient, what's the mapping 
between these version numbers

Thanks

Ken

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

crash entering notes tab of a particular project

Hi,

I get an ogo crasher when I click on the notes tab of a particular project. 
The ogo instance dies because it received signal 11.

So I thought it could be that one of the notes is causing a problem, I think 
those are saved in the "note" table in the database, but for that particular 
project, no note is saved. The project_id for the project is 55250, and the 
following query doesn't produce anything:
SELECT * from note where project_id=55250;
I also thought when a note is appended to an appointment, and the note is 
assigned to a project, that is also not the case, as it would have been shown 
up with above query.

I can enter other projects notes tabs, without problem, doesn't seem to matter 
whether there are notes assigned or not.

It doesn't seem to be user dependent, as other users have the same problem 
entering the notes tab of that particular project.

To get a backtrace, I first need to get the VM copied and prepare a test 
system.... So any hint on how to figure out without disrupting the work of 
others, would be great

ogo-trunk_r2169
sope-trunk_r1629
libfoundation11-1.1.7-r168.1
on SLES 10 SP1 x86_64

cheers
Sebastian
--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

ALERT: Database schema changes in trunk.

For users of trunk (v5.5) r2271 and later require a database schema
change.

Details:
------------
<http://whitemiceconsulting.blogspot.com/2009/09/new-ogo-help-desk-feature.html>

Enhancement Bug#2027 "Allow help desk users to create tasks on behalf of
users" has been resolved as of r2274. This update requires a database
schema change -

ALTER TABLE job ADD COLUMN owner_id INT;
UPDATE job SET owner_id = creator_id;

The database scripts pg-build-schema.psql and pg-update-1.x-to-5.5.psql
have been updated. NOTE: Be careful not to run this part of
pg-update-1.x-to-5.5.psql more than once or you risk modifying actual
data in your database if you use the OGoHelpDeskRoleName default.

This feature allows a member of the team whose named is defined in the
OGoHelpDeskRoleName default to create tasks with an owner other than
themselves. Delegated and archived task lists now display tasks based on
owner rather than creator. By default the owner is the creator so this
has no effect on normal task behaviour. Currently the help desk feature,
setting of the owner to another user, is only available via the zOGI
API. The modifications to the zOGI API are documented on the Task
entity.

If your help desk team name contains spaces be sure to use proper
quoting - Defaults write NSGlobalDomain OGoHelpDeskRoleName '"all
intranet"' - or you may not get the results you expect. Obviously if you
set OGoHelpDeskRoleName to "all intranet" all users will be able to
create tasks on behalf of other users. 

Links
--------
<http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=2027>
<http://svn.opengroupware.org/OpenGroupware.org/trunk/Database/PostgreSQL/pg-update-1.x-to-5.5.psql>
<http://svn.opengroupware.org/OpenGroupware.org/trunk/Database/PostgreSQL/pg-build-schema.psql>
<http://code.google.com/p/zogi/wiki/Task>

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

documents standard attributes

Is there a way to configure what (standard) attributes appears in OGo 
documents webui (e.g., attributes for a file stored in a db project) via 
Defaults ? Is this an extensible set?

Thanks in advance, Renzo Vettori

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users

Install OpenSuse Build Dated 26 Jun on Centos5 with Yum: Table ctags missing in schema

Hello list,
I just subscribed to ask for a solution to a problem that I managed to
clear myself. I think other people will stumble over it so I'm posting
to preserve the info for others:

SETUP:

Centos 5.3 Base install with Gnome Desktop

Added following repository:

[server_OpenGroupware]
name=OpenGroupware.Org Groupware Server & Collaberation Platform (CentOS_5)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/server:/OpenGroupware/CentOS_5/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/server:/OpenGroupware/CentOS_5/repodata/repomd.xml.key
enabled=1

INSTALL:

yum install ogo-meta-5.5-8.2 ogo-database-setup-1.1-14.2
Everthing installs nice an the server is up and running.
Browsing http://localhost/OpenGroupware works fine

PROBLEM:

Changing the password leads to a "Check Password" Error which links to
following line in the logs:

name:   PostgreSQL72FatalError  reason: fatal pgsql error
(channel=<0x0x9cb52c4[PostgreSQL72Channel]:
connection=<0x0x9cb54ac[PGConnection]:  connection=0x0x9cb5ce0>>):
ERROR:  relation "ctags" does not exist

SOLUTION:
The Suse Build is from the 26-Jun
I found
http://mail.opengroupware.org/pipermail/developer/2009-June/003812.html
which was already checked in before 26 Jun.

Apparently the schema files

/usr/lib/opengroupware.org-5.5/commands/OGo.model/Resources/pg-build-schema.psql
/usr/share/opengroupware.org-1.1/dbsetup/PostgreSQL/pg-build-schema.psql

were not updated to represent this change and are missing the ctags table.

So just add it:

CREATE TABLE ctags (
  entity VARCHAR NOT NULL,
  ctag  INTEGER NOT NULL DEFAULT 0
);

INSERT INTO ctags (entity) VALUES ('Person');
INSERT INTO ctags (entity) VALUES ('Enterprise');
INSERT INTO ctags (entity) VALUES ('Date');
INSERT INTO ctags (entity) VALUES ('Job');
INSERT INTO ctags (entity) VALUES ('Team');

Hope that my description is clear enough and helps others.
Should I open a bug somewhere or post to developper list?

Have fun Marc

--

-- 
OpenGroupware.org Users
users <at> opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/users