Hi Ludovic,
I was unable to find out how it should work correctly. Could you give
more details?
I tried both methods and created a SOGoUserSources from your example.
Now, I can see "resources" like the global addressbook and in it my
test-resource "room-a". But the test-resource "room-a" is an ordinary
"address" and not a special resource.
Does the webinterface no work with resouces yet?
I thought that resouces are shown in the calendar with a begin-/end-date.
Greetz,
Martin
@ludovic: I've created a schema from the draft for me. But there were
some errors in the draft so I'd to fix it and I've assigned a OID for
the placeholder "x" in the draft. This solution works for me. If you're
interested I can send it.
On 04/25/2011 02:38 PM, Ludovic Marcotte wrote:
Hello,
A new feature has just landed in the SOGo code: resources planning.
It's now possible to tell SOGo how to identify resources (conference
rooms, projectors, etc.) and apply constraints on them to avoid
double-bookings and to automatically accept the "invitation" for them.
This works right now only over LDAP and you can identify resources
using either :
a- the "calendarresource" objectClass (see
http://tools.ietf.org/html/draft-cal-resource-schema-03)
b- a specific LDAP attribute (specified by the "KindFieldName"
parameter in your SOGoUserSources) which must hold either "location",
"thing" or "group" (also see the URL above)
Then, you must also set how many simultaneous bookings are allowed for
this resource. A value of "0" means no limit. This limit is also read
from a LDAP attribute specified by "MultipleBookingsFieldName".
If SOGo can't determine it's a resource, the code will work just like
it did before - meaning that someone must accept/decline the
invitation for the resource. If it can, the following scenarios are
possible:
1- automatically accept the invitation for the resource if there's no
conflict
2- prevent save operations if there's a conflict (ie., someone tries
to use a resource already scheduled for an other meeting)
A SOGoUserSources entry which can handle resources might look like :
{
CNFieldName = cn;
IDFieldName = uid;
KindFieldName = description;
MultipleBookingsFieldName = multiplebook;
UIDFieldName = uid;
baseDN = "dc=inverse,dc=ca";
bindDN = "cn=sogo,ou=services,dc=inverse,dc=ca";
bindPassword = zot;
canAuthenticate = YES;
displayName = "Partag\U00E9";
hostname = "127.0.0.1";
id = public;
isAddressBook = YES;
port = 389;
},
while a resource defined in LDAP *could* look like :
dn: uid=room103,ou=resources,dc=inverse,dc=ca
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: room103
mail: room...@inverse.ca
cn: room103
sn: room103
multiplebook: 1
description: location
Nightly builds are being regenerated and should be available in less
than 30 mins with that code in.
Regards,
--
users@sogo.nu
https://inverse.ca/sogo/lists