Ludovic --
This resource planning is great. I have a few questions on setting it up:
1) If using the CalendarResource object class, do I need to set SOGo the
lines:
KindFieldName = Kind;
MultipleBookingsFieldName = Multiplebookings;
2) Can I put resources into a canAuthenticate=No addressbook? Or do
resources have to look like 'real people that can logon'?
3) What is the minimum I need in a resource ldif entry?
Currently I have:
dn: cn=ResourceTest,ou=people,dc=company
objectClass: organizationalRole
objectClass: top
objectClass: CalendarResource
cn: ResourceTest
Multiplebookings: 1
Kind: location
Do I need to have a sn set? mail? With this ldif entry, I have the
resource show up in the addressbook, but not when I try to invite people
to an event.
Thanks,
Ben
On 4/25/2011 6:38 AM, 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: [email protected]
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,
--
[email protected]
https://inverse.ca/sogo/lists
