Features within Public Bookings
Magnity - December 17, 2008 - 21:15
| Project: | Public Bookings |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
Description
Hi,
Public bookings is a very good starting for what I need (and I'm sure many others).
However there are a couple of things that could make it a lot better
- Permissions to control who can create a booking (then perhaps add-on module to control resources per role similar to cck fields)
- Bookings linked to user records - booking name defaults to username
- Simplified bookings forms to allow just name, resource, time.
- Simplified resource forms to allow just name, availability settings.
Would this sort of thing be possible? It is hard to see from the README.txt as to whether this is included (e.g. "more settings")
#1
In the middle-run we will rewrite Bookings API and Public Bookings to use node-type resources, instead of the currently used custom one. This will allow some more advanced features, including a more detailed control over resource permissions.
Could you elaborate what you meant with your second proposal? As far as I understood you, this would only work for registered users. The administrative view on bookings would then show, which user a booking belongs to, correct? If yes: Yes, I believe this would be a good idea, though possibly in an additional module (together with booking permissions).
Resource form customization will be available only after the resource type has been changed - but it will be available. The same applies to booking form customization, though a custom module using the Bookings API would be possible. I would recommend waiting for the rewrite before starting to develop custom modules though, the API will change.
#2
It could work with anonymous users by associating them with user 0 - and having a rule that user 0 cannot edit its bookings...
My usage would be almost entirely for registered users so the reason that i'd like to see them associated is so that users can edit/cancel bookings.
Thanks,
#3
At the moment users can edit bookings using passphrases - but I agree, allowing registered users to edit their own bookings would be nice (at least: Leaving the administrator the choice of doing so).
#4
This module is great. Are there any plans to be add features for associating images or media galleries with resources? Maybe there is already a way to do that and I've missed it but that would be really cool.
#5
ATM this is not possible. It will be possible with node-bases resources.
#6
Hello, I would like to summarize what's been said in this trait and add some of my own wishes.
If I understand it well Magnity wants the possibility to allocate different bookings to different Admins (specifically set roles to handel their bookings), in the way that only that specific admin wil be able to view, confirm, edit or deny the booking made. If so, I like this idea very much, since it allows for (e.g.) a platform to host the bookings from different parties for a big audience. And all this without interfering with some other parties' bookings.
Secondly I think it would be very desirable to be able to edit the Booking form. For example I need the standard form including some specific questionnaires relevant to the object being booked in order to determine if the one booking applies.
When is the rewrite planned to be finished ? Anyhow, good luck along the way !
Grts,
8tropos
#7
a) Several different admins - should be possible. If not within Public Bookings, then it will be possible to add a module to support this
b) Editable bookings form - I believe this would best be solved within an additional module, adding new fields. But this will definitely be possible
Regarding the timeframe .. sorry, but at the moment I really cannot say more then "its done when its done" (I hate those statements, but I cannot give anything more specific. Sorry.) We are evaluating several possible methods to add node-type resources (e.g. fixed types, fixed fields, free fields, etc) and are still testing which method would be best.
Thanks for the feedback :)
#8