SOGo | BTS

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000003SOGoBackend Calendarpublic2009-04-16 05:062011-04-25 08:15
ReporterVooDooMaster 
Assigned Toludovic 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version1.3.7 
Summary0000003: Feature Request: Ressource Planning
DescriptionA possibility to manage "Resources" like notebooks, beamers, conferencing rooms, ... (seen in eGroupware) would be very nice
Additional Informatione.g.:
Make an appointment (and invite some colleagues) and reserve
"conferencing room 2", the "large beamer" and the "CAD-notebook"

TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0001095)
roberto (reporter)
2010-06-05 09:57

+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... :-(
User avatar (0001308)
ludovic (administrator)
2010-08-16 12:54

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.
(0001396)
roberto (reporter)
2010-08-30 15:00

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.
(0002035)
Stefan Helms (reporter)
2011-01-20 11:29
edited on: 2011-01-20 12:28

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?

User avatar (0002406)
ludovic (administrator)
2011-04-25 08:15

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

- Issue History
Date Modified Username Field Change
2009-04-16 05:06 VooDooMaster New Issue
2010-06-05 09:57 roberto Note Added: 0001095
2010-08-16 12:53 ludovic Status new => assigned
2010-08-16 12:53 ludovic Assigned To => ludovic
2010-08-16 12:54 ludovic Note Added: 0001308
2010-08-30 15:00 roberto Note Added: 0001396
2011-01-20 11:29 Stefan Helms Note Added: 0002035
2011-01-20 11:32 Stefan Helms Note Edited: 0002035
2011-01-20 12:08 Stefan Helms Note Edited: 0002035
2011-01-20 12:09 Stefan Helms Note Edited: 0002035
2011-01-20 12:12 Stefan Helms Note Edited: 0002035
2011-01-20 12:27 Stefan Helms Note Edited: 0002035
2011-01-20 12:28 Stefan Helms Note Edited: 0002035
2011-04-25 08:15 ludovic Note Added: 0002406
2011-04-25 08:15 ludovic Status assigned => resolved
2011-04-25 08:15 ludovic Fixed in Version => 1.3.7
2011-04-25 08:15 ludovic Resolution open => fixed


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker