Re: [MRBS-general] Search results in e.g. week view

[S. O. <so...@on...>]

Hi again Campbell (et al),
I've been giving it some thought as well.

I think it could be solved by implementing only a single feature:
* allow for the booking of multiple rooms in a single booking

To make thing easier to comprehend, it would also be a good idea to
change the designations 'area' to 'resource group' and 'room' to
'resource'

For me, the most important issue is to be able to view calendars (week,
month, list) for an individual as well as rooms.

Assuming the features were implemented, I could solve my issues this
way:
Create two 'resource groups' called 'rooms' and 'individuals'
Make appointments which include a room and an individual
Use existing views to view rooms or individuals as needed.

When looking at e.g. the week view of a room, any other resources booked
in an appointment should simply be listed inside under the booking
title.

This would allow for a lot of flexibility:
- you could create a resource group called 'equipment' with resources
called 'laptop 1', 'laptop 2', etc
- you could create a resource group called 'team 1 personnel' for
individuals in team 1
- you could create a resource group called 'rooms in building 1'
etc.

That way, I could book 'team 1 personnel'/'Peter', 'team 2
personnel'/'John', 'rooms in building 1'/'Conference room' and
'equipment'/'Laptop 1' and 'equipment'/'Video camera 3' for a single
appointment.

For me (as a human being), it's implied that Peter and John meet IN the
conference room USING a laptop and camera, but that's not important in
terms of the data structure or coding, re. your thoughts on mobile vs.
flexible rooms.

This way I could get a nice overview of the bookings of 'Conference
room', as well as Peter Schedule or the use of laptop 1.

Initially, I though it would be necessary to also allow for conflicting
bookings, but actually I don't think so. Give that some thought (I't
will screw up the views :-)

Regards
Soren



On 28/09/2012 12:20 "Campbell Morrison" <cam...@gm...>
wrote:

> I've been thinking a little bit more about this problem. Here are my
> latest thoughts below, on which I'd welcome feedback. There's
> obviously a lot more thinking to be done, but I thought I'd throw this
> out at this stage to see if it's vaguely in the right direction.
> 
> Campbell
> 
> 
> 
> REQUIREMENTS
> 
> - To be able to book one or more resources (eg a teacher or a
> computer) at the same time as a room
> - To be able to book resources without a room (perhaps to block out a
> teacher as unavailable, or perhaps to take a computer off site)
> - To be able to get calendar views for a resource (eg see a teacher’s
> schedule for the week)
> 
> 
> PROPOSED SOLUTION
> 
> The essential characteristic of the examples above is that the
> resources are mobile whereas rooms are fixed. So it makes sense for
> example to be able to book a room plus two computers, but it does not
> make sense to be book a computer plus two rooms, as we’ll assume that
> a computer can’t be divided between two rooms. (I suppose it is
> possible in some cases for a mobile resource, eg a teacher, to be
> shared between two rooms, but to keep things simple we’ll assume that
> that can’t happen).
> 
> The proposed solution is add an extra property to areas, a boolean
> field in the areas table, specifying whether “rooms” in that area are
> fixed or mobile. (For the moment we will continue to use “rooms” as a
> general term for resources, fixed or mobile, and “areas” for a group
> of “rooms”, though it might be more sensible in due course to think
> about renaming them to something more generic, eg “resources” and
> “resource groups”).
> 
> A fixed room is a room that is a member of a fixed area. A mobile room
> is a room that is a member of a mobile area. On upgrade, all existing
> areas are assumed to be fixed. Treating mobile resources as just
> another room immediately enables the day/week/month views to work
> unchanged. Similarly Search and Report should also work unchanged,
> though Report could benefit from some extra search fields to
> distinguish between mobile and fixed areas and rooms.
> 
> The major change would be to the booking form and handling, which
> would have to be enhanced so that:
> - When booking a fixed room, one can optionally book any number of
> mobile rooms at the same time
> - If more than one fixed room is selected then it should not be
> possible to book any mobile rooms at the same time
> - When booking a mobile room, one can optionally book a single fixed
> room at the same time and any number of other mobile rooms.
> 
> The changes to the database would need to be thought about a little
> more, but essentially an entry, instead of referring to a single room,
> would now consist of a number of rooms, probably held in a separate
> table.
> 
> However this solution would enable you to have for example an Area
> called "Maths Teachers" and then the Day view would show you the
> schedule for all the Maths teachers for the day. Similarly the Week
> view would show you a single teacher's schedule for the week.
> (Subsequent refinements might be to show the fixed room that they were
> in - perhaps instead of/as well as the booking name, or perhaps by a
> colour key. Needs more thought)
> 
> 
> 
> 
> 
> From: Søren O'Neill [mailto:so...@on...]
> Sent: 18 September 2012 12:00
> To: <mrb...@li...>
> Subject: Re: [MRBS-general] Search results in e.g. week view
> 
> Hi Campbell,
> sounds great -- I look forward to it
> 
> Regards
> Soren
> 
> tir, 18 09 2012 kl. 10:53 +0100, skrev Campbell Morrison:
> Hi Soren – yes the thread went quiet but it hasn’t died out! I’m still
> intending to do something here as this seems to be a fairly frequently
> requested feature. I’ll post some more thoughts in the next few days.
> 
> 
> 
> Campbell
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Søren O'Neill [mailto:so...@on...]
> Sent: 18 September 2012 08:21
> To: General purpose list (support/developers/users)
> Subject: Re: [MRBS-general] Search results in e.g. week view
> 
> 
> 
> Dear MRBS developers,
> this thread seemed to die out, unfortunately.
> 
> I'm still interested in a solution and would like to donate a
> reasonable amount of money for the work.
> 
> Just to re-cap : what I need is a degree of resource management added
> to MRBS, such that a particular booking could include one or more
> named resources. Resources should be generic, so that I might include
> people. The important thing, is that MRBS could display calendar views
> based on resources in the same manner that it can currently display
> the calendar for rooms.
> 
> I hope someone would like to add that functionality to an already
> excellent FOSS project :-)
> 
> Kind regards
> Soren O'Neill
> 
> tor, 12 07 2012 kl. 09:14 +0200, skrev Diego Zuccato:
> 
> 
> Il 11/07/2012 22:43, Campbell Morrison ha scritto:
> > I'd started thinking about this and wondered whether a solution
> > would be to introduce a level above Areas, let's call it a
> > "Category", and then allow you to book at most one resource
> > from each category. For example you might have a category
> > called "Classrooms", a category called "People" and a category
> > called "Equipment".
> Interesting.
> > You could have as many categories as you like but on the booking
> > form you could only ever book one resource from each category.
> Why such a limitation? You only need one more table.
> 
> > This would then map onto existing MRBS quite nicely as you'd
> > introduce a category table and have each area belong to a category.
> > It would also be easy to view the system from the viewpoint of
> > any category.
> Uh?
> 
> > However then it occurred to me that maybe this wouldn't work, as
> > you might well want to assign more than one computer, and/or
> > indeed more than one person to a room.
> That's quite for sure :)
> And add to that that some resources could be available only for
> specific
> rooms...
> 
> > So do you then have a concept of the "main category", eg a room,
> > with all the other categories, eg people and equipment, being
> > secondary? And when you make a booking you have to have at
> > least one resource from the main category and then optionally
> > multiple resources from the secondary categories?
> No need for that. Unless you want that something is bookable only
> bundled with another resource, that would make it slightly harder.
> 
> > (Of course if you tried to book two rooms in the one booking,
> > as you can in MRBS at the moment, and then asked for secondary
> > resources, that would throw up a conflict immediately.
> > So if you were going to book secondary resources, you'd only
> > be able to do it if you'd selected just one room.)
> No need for that, see below.
> 
> > At that point I stopped because no doubt someone out there has
> > already thought about the problem and solved it, or seen another
> > system that has solved it.
> > Any thoughts?
> To allow multiple "atomic" bookings, you should use a long-lasting
> transaction while the user is selecting resources. Something like:
> 1) click "multi-resource booking": that starts the transaction adding
> a
> row to "transactions" table (integer tID, timestamp start, timestamp
> lastActivity, bool confirmed)
> 2) book all needed resources the usual way: they get booked as usual,
> but new "transID" column is set to the current transaction ID and
> every
> booking updates transactions.lastActivity
> 3) click "confirm booking": simply sets to true
> transactions.confirmed;
> if the user clicks "discard booking", then every booking referencing
> current transaction can easily be removed when deleting current (SQL
> "on
> delete cascade" might help :) )
> 
> This way other users can't book resources being multi-booked. And it's
> easy to have a timeout on a transaction (now - lastActivity > timeout)
> so that resources are freed even if the booker "forgets" to cancel his
> booking. To avoid DOS (and allow for "roaming" users) any user can
> have
> at most one open transaction.
> 
> No need to book multiple rooms in a go, since you can atomically
> book'em
> anyway.
> 
> And, BTW, capabilities would perfectly fit here :)
> Just add "in_transaction" and "current_room" caps automatically
> populated, and you can easily check if a "secondary" resource is
> bookable.
> 
> --
> Diego Zuccato
> Servizi Informatici
> Dip. di Astronomia - Università di Bologna
> Via Ranzani, 1 - 40126 Bologna - Italy
> tel.: +39 051 20 95786
> mail: <die...@un...>
> 
> 
> 
> LA RICERCA C’È E SI VEDE:
> 5 per mille all'Università di Bologna - C.F.: 80007010376
> <http://www.unibo.it/5permille>
> 
> Questa informativa è inserita in automatico dal sistema al fine
> esclusivo della realizzazione dei fini istituzionali dell’ente.
> 
> ----------------------------------------------------------------------
> --------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions
> will include endpoint security, mobile security and the latest in
> malware
> threats. <http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
> _______________________________________________
> mrbs-general mailing list
> <mrb...@li...>
> <https://lists.sourceforge.net/lists/listinfo/mrbs-general>
> Want to unsubscribe:
> mailto:mrb...@li...?subject=unsubscribe
> 
>