Re: [MRBS-general] Search results in e.g. week view
Brought to you by:
jberanek
From: S. O. <so...@on...> - 2012-09-29 18:43:24
|
True ... it will be booked in the sense that we (humans) know it can't be in two rooms at the same time, but in terms of the data structure, what will happen is simply that it will show up in the views of room A and room B and the computers own view will list two rooms as booked resources. One solution could be: - if two resources (from the same group) is selected in a new booking we must assume, it's because it makes sense -- e.g if laptop A and laptop B are both booked with room A - if, for a new booking a resource is selected which is already booked, a warning is raised -- e.g if laptop A and laptop B are both booked with room A and laptop A is already booked in that period a warning is raised. regards Soren On 29/09/2012 17:17 "Campbell Morrison" <ma...@ca...> wrote: > But what happens if I book Room A and Room B and a computer? The > computer is then double booked. That's why I think you need to > distinguish between fixed and mobile resources. If you are going to > book a mobile resources, eg a room, then you can only book one fixed > resource. > > Campbell > > > On Sep 29, 2012 3:14 PM, "Søren ONeill" <<so...@on...>> wrote: > > > 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 <tel:%2B39%20051%2020%2095786> > > > 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=unsubs > > > cribe > > > > > > > > > > |