#286 Viewer-Requester-Controller-Admin


We use MRBS as follows: One administrative account with [ADMIN] privileges, and a dozen room [CONTROLLERS]. Everyone else gets to [VIEW] only. {0,1,2 levels of access}

The [ADMIN] account remains clear of the booking process - only getting involved if required. Our [CONTROLLERS] work independently, but communicate with each other. The [CONTROLLERS] each have their own login ID's but we have elected to use a common password. The separate [CONTROLLER] ID's creates an audit trail, and the common password is tempered by communication and assignment of primary ownership of certain rooms. This makes it easy for controllers to arbitrarily book their own rooms... and yet, any [CONTROLLER] is able to cover for another during absences. [VIEWER] users get to look at the calendars - but make no changes.

In the interest of reserving [ADMIN] level rights, and streamlining our process toward relieving input workload for the [CONTROLLERS] -- we would like to set up one more level of access. A [REQUESTER]. Essentially... a [REQUESTER] account would be able to enter booking details into apparently free space for any room, and submit the booking for approval. The [REQUESTER] might be able to edit their own existing entries... but that's it. They cannot approve or delete their entry.

The [ADMIN] remains as is -- primarily managing and maintaining the system itself. There would still be a dozen [CONTROLLERS] co-managing and editing/approving the actual rooms. Different, would be a new layer of persons, [REQUESTER]s entering the bulk of the data toward booking their meeting spaces. Finally, there remains a large majority who is: everyone else. Those happy, just to [VIEW]. {0,1,2,3}




Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks