Two systems with the same bookings, fiddle with dbsys.inc?

[jberanek]

[Transferred from the general mailing list]

Hi, we are running a very old 1.4.9 version of the MRBS, but it does the job and we've some local tweaks that have put me off upgrading. Though a quick look doesn't seem to have the option I'm looking for.

Short version:

I can create a clone of our existing setup (data and files) and it runs as an independant service. But could I hack the dbsys.inc, so that the clone uses its own tables apart from the _entry and _repeat tables. Thus both systems would be working on the same actual room bookings, but on the clone I could choose to hide rooms or areas?

I realise that adding/deleting rooms/areas would lead to issues, but I only want to toggle the visibility of them.

Thanks,

Neil

The longer teason for my request:

During the covid stuff, we've removed most people's abilty to book rooms (apart from the admin) but as the building reopens, we want to start enabling limited bookings to some staff. We could do this by hiding the rooms that are still not generally available to bookers.

But we'd also like the admin people to still have a full view of all the rooms, and make bookings in the rooms hidden to the others.

My initial quick fix was just going to be new covid version with just the rooms required, but at some point we'd like to then migrate any bookings made in that copy, into the original system.

So I'm just wondering if I can somehow fudge two systems (each with their own code - config.inc.php etc), but share the actual room booking data (but just the bookings). It looked like I could hack the dbsys.inc on the cloned site to use a different prefix for those two tables.

$tbl_entry = $db_tbl_prefix . "entry"; $tbl_repeat = $db_tbl_prefix . "repeat";

As long as the room and area ids remain in sync, I'm hoping it would "just work"!

Neil

Reported by: campbell-m

Original Ticket: mrbs/support-requests/2154

[jberanek]

Yes, I think that would probably work, though there may be some gotchas that I haven't thought of.

Another way of doing it would be to keep a single system, but modify the function getWritable() in mrbs_auth.inc. This determines who can make bookings in a room. Those who couldn't book would still be able to see the room and the booking though - I don't know if that's a problem? You could prevent them seeing the contents of the booking by forcing bookings to be private, though they'd still be able to see whether the room was free or busy.

In MRBS 1.9.0 there's also a function is_visible($room) which controls whether a room is visible.

And under development is the concept of Roles which will allow you to control whether a user can see/book/administer a room - but that's a few weeks away yet.

Original comment by: campbell-m

[jberanek]

Thanks for that. I didn't think it warranted an official support request, it was supposed to be just me thinking out loud, but your advice is much appreciated.

To avoid confusion, it would be best if I could just hide the rooms that aren't generally bookable yet, but I'll look at getWriteable().

Actually, you can move rooms easily between areas. So a compromise could be to look at the getWritable() function, and create a new area for the rooms that are bookable, and move those rooms to there. And make that the default area when someone visits the site.

Cheers,

Original comment by: *anonymous

[jberanek]

I should have logged in first!

Original comment by: spiralarms