Table of Contents

See also: Bumblebee User's Guide.

Bumblebee Philosophy

To understand how Bumblebee will report the usage of your instruments and calculate the costs associated with this, you will need to understand how Bumblebee views the relationships between users, and the research groups to which they would belong. The system has been designed to allow the maximum flexibility and with flexibility comes a little complexity; however, it is still straightforward to use Bumblebee in situations which do not require the layered management approach used here.

Bumblebee uses a three-tiered approach to the problem of accounting for instrument usage incorporating "Research Groups", "Projects" and "Users". Between each of these tiers there is a many-to-many relationship, which is where the flexibility comes in. The structure is exactly what one has in a modern collaborative research environment, although the way it is codified here might seem perculiar at first:

A user is an individual person who is able to log in with a username and password. User accounts are not shared between people, just as you would not share an email address. Each user may be working on one or more projects and is able to use one or more instruments.
A Project is a particular piece of work being undertaken by one or more users. The scope of a Project is anything you want and depends largely on how fine-grained you want the reporting information to be. For many uses of Bumblebee, it is sufficient to have all researchers in a (smallish) research group working on the same Project. Others want to have very fine-grained reporting capabilities so each PhD student may have their own Project. Each Project will have one or more users working on it. In turn, each Project will be undertaken by a Research Group or it may even be a collaboration between Groups where the costs are shared between the groups according to some formula. Each project will also have a particular charging band associated with it (e.g. external rates, internal rates, free access etc).
A Group will frequently be an entire research group (like Prof. Jane Smith's research group that we will look at below), although for easier accounting and reporting to competitive granting bodies, some sites will find it easier to have a separate Group for each grant account that will be charged. Each group may have a number of projects within it.

Users/Projects/Groups example

To explore this further, consider the research group of Prof. Jane Smith.

Prof. Smith has a number of researchers working for her in two main areas (Ceramafiable Olefins and Cold Fusion). Most of her researchers are working on just one of these projects; however a Dr John Citizen, a post-doc working with her is working across both of these areas. The relationship between the Groups, Projects and Users for Prof. Smith's research activities could be represented as follows:

Groups, Projects and Users
Groups, Projects and Users for Prof. Jane Smith's research activities

As Prof. Smith is a leading researcher in her field, she also has many collaborative projects. In particular, she has started a new research project on Doppler Gravity Measurements in collaboration with Prof. Robert Jones. They agree to share the costs of doing this research 50:50. A PhD student will be working on this project along with Dr Citizen, Prof. Smith's post-doc. The above diagram can now be expanded to include this collaboration.

Collaborations with Groups, Projects and Users
Including collaborations with Projects and Groups

Accessing Administrative Features

Admin menu
Full menu including administrative functions

The various administrative features of Bumblebee are accessed from the menu that is displayed on each page. While logged in as a regular user, this menu does not include the admin functions; while logged in as a user with administrator privileges, the full feature set is shown.

Deleting Users, Projects, Groups etc

Note that when you "Delete" Users, Projects, Groups, the entries for these objects are not actually deleted from the database, merely marked as deleted. Consequently, they can be easily undeleted using the Undelete interface (where provided) or a tool such as phpMyAdmin. The objects are not deleted to ensure the integrity of the data that is already in the database; for example, if you were to delete a user from the database, then all the bookings made by that user would become invalid data in the database and your log book and billing summaries would contain strange entries.

Last edited: Wednesday April 19, 2006

Valid XHTML 1.1 Valid CSS 2