+1 for this feature! It'll be a great achievement, which - even small - company doesn't need to manage ressource reservation? Where I work (NGO) we're trying to tie SOGo with phpscheduleit... :-(

Resources should each have a calendar associated with them.

We could provide options to auto-accept/auto-reject invitations for those if the calendar belongs to a resource.

Some ideas I've seen deployed with other software:
· Some resources require authorization, some don't.
· Some users can be resource administrators and may delete a reservation.
· Ressources can be scheduled without an associated event.
· Any other ideas you want to discuss or share just mail me! :-) TIA.

Another STRONG +1!

My suggestion:

• Each resource is a regular user
• Add a GUI option to any useraccount to automagically accept/reject invitaions (plus a field to configure in which calendar automatically accepted appointments are stored)
• If no conflicting appointment (time overlap and (status accepted or tentative)) exists in this "autoaccept" calendar => accept appointment on creation
• If conflicting appointment exists => decline and inform sender about the organizer of the conflicting event (so they can fight it out)

[It would be cool if resources would work without an IMAP account (invitations directly injected into the db tables, not via mail): In our environment the IMAP-/LDAP-servers are managed centrally and only real persons are granted an account. Our department has an own LDAP (Active Directory) configured as a secondary SOGoUserSource for resources and those currently have alias/distribution-list addresses configured being delivered to the IMAP accounts of their respective managers.
PLEASE let's not start a discussion about how sensible/braindamaged this infrastructure is, it's due to politics and history and considering my tight schedule I would prefer not to engage in politics.]

Rationale:

• Easy to implement and manage
  • No special infrastructure or object types needed
  • Existing free/busy can be used for resources without further changes
• Transparent to the user (just invite a resource like anyone else)
• Easy to switch a resource between being selfmanaged (autoaccept activated) and controlled (autoaccept deactivated, manually accepted/declined on behalf by a resource manager)
• Easy to transfer managed resources to another manager (change ACLs and mail forwarding)
• Existing ACLs can be used to make someone a resource manager

Until anything like this is included in SOGo, I would really love to hack around this huge shortcoming by scripting a cronjob performing the necessary checks and changes to the database tables directly.
But to do this I would need a documentation of the database schema including the correlation between content and "quick" tables (that seems to be quite a strange implementation btw - or maybe it's because I don't understand).
So far I couldn't find anything.
Can anyone please help me out on this?

Implemented with http://mtn.inverse.ca/revision/diff/be9e28d5d42ed05605b27d2127cf29b07678495b/with/5de6a9584cf27a2c1dad8d1ab8b84fc9ddab2720