ResourceBookingSystem

Interface calendar / rbs

rbs --> Resources Management

• Resources should be "users" of the calendar but not be egw users.
• Resources are managed in categories
  
• Resources could be created by "some" egw users and be assigned to a categorie.
• Each categorie has one egw user who is responsible for the whole cat.
  
• In this stage the calendar is not affected. If resources need to be schedulable (e.g. rooms) they could be "hooked" into calendar.
  
• Any resource has an own ACL. Who is allowed to book, who is allowed to watch it's calendar, who is allowed to send requests...
  
• The rbs also could handle resources which does not need to have a schedule (e.g. a coffeemachine). These resources are also assigned to a categorie an so there is a egw user, which is responsible for that resource.
  
• eGW users can browse resources, see who is responsible for them, where they are stored.
• This could be a list similar to the address list:
• searchable.
  
• buttons at the end of each entry: view details / view calendar / delete / edit
  
• but entries have no owner, they all belong to the app itselve.
• Fields needed for each resource:
  
• name of resource
  
• short description
• picture(s)
  
• quantity
• usable (how many of them are ok?)
  
• category
• checkboxes --> is bookable? / is byeable?
  
• location
  
• ... (detailed location / storage information)
  
• pricing
• ... (detailed information of booking / buying prizes
  
• resources could also have an own info-page.
  
• accessories
  
• ...
• Thus, rbs becomes more as "just" a Resource Booking System. It becomes a Resources Management(RM) which is flexible to the users needs and could maybe in future be extended to some kind of a shopping system.
  

Schedulable Resources

• There are two modes in the resource booking procedure.
1. The user who wants to book a resource is allowed to do so. If he books a resource, it is booked.
2. The user who wants to book a resource NOT allowed to do so. Then the user's request goes to the responsible person of the resource and he can decide if the resource becomes booked or not. Note: The requesting user could also be a website-user.
   
• A user can create unique calendar views via the checkboxes in the resources list.
  

Interface to calendar

• Calendar needs to provide a method like "CreateNewResouce?(...)"
• Resources should be treated as resources. If a user makes a normal entry into the calendar, he should be able to select resouces he wants to book. An idea for the selection field is to sort the users/groups/resources first after their type. users (u), groups(g), resources(r). And secondly in alphabetic order. Another idea is to provide two or three selection fields, with these types.
  
• Thus, each resource has a responsible egw user, the mail adresses for the booking procedure are clear.
• Calendar needs to provide a flexible way to create different views, e.g.
• showcalendar(groupview,starttime,endtime,resource1,resource7,...)
• showcalendar(groupview,starttime,endtime,resourcecategory1)