The data module describes the conditions and collection of data regarding experimental animals.
Data (or measurements) can be stored for any type of measurement. Conceptually, several pieces of data belong to an experiment (for example several mice are measured at some time) and several experiments belong to a study. Measurements can be stored independent of experiments and experiments can be performed outside of the context of a study. It is however, perfered that measurements are stored within an experiment and experiments are stored within studies as this will greatly facilitate the organization of the data.
In general studies are a collection of experiments. These can be grouped together on the basis of animals and/or treatment groups. A study must have at least one treatment group, which defines the animals and their conditions.
An experiment is a collection of measurements for a given set of animals. In general, an experiment is defined as a number of measurements take in a given day.
A measurement is an animal, an assay and a measurement value. It can be associated with an experiment, or can stand alone as an individual value. Measurements can be viewed in the context of a study, an experiment, a treatment group or an animal by going to the appropriate page.
The animal app contains and controls the display of data about animals.
Animals are tracked as individual entities, and given associations to breeding cages to follow ancestry, and strains.
Most parameters about an animal are set within the animal object. Here is where the animals strain, breeding, parentage and many other parameters are included. Animals have foreignkey relationships with both Strain and Breeding, so an animal may only belong to one of each of those. As an example, a mouse cannot come from more than one Breeding set, and cannot belong to more than one strain.
For this software, optional tracking of backcrosses and generations is available and is stored as an attribute of an animal. When an inbred cross is made against a pure background, the backcross increases by 1. When a heterozygote cross is made, the generation increases by one. As an example, for every time a mouse in a C57/BL6 background is crossed against a wildtype C57/B6 mouse, the backcross (but not the generation) increases by one. For every time a mutant strain is crosses against itself (either vs a heterozygote or homozygote of that strain), the generation will increase by one. Backcrosses should typically be performed against a separate colony of purebred mouse, rather than against wild-type alleles of the mutant strain.
A breeding cage is defined as a set of one or more male and one or more female mice. Because of this, it is not always clear who the precise parentage of an animal is. If the parentage is known, then the Mother and Father fields can be set for a particular animal.
A strain is a set of mice with a similar genetics. Importantly strains are separated from Backgrounds. For example, one might have mice with the genotype ob/ob but these mice may be in either a C57-Black6 or a mixed background. This difference is set at the individual animal level. The result of this is that a query for a particular strain may then need to be filtered to a specific background.
This module describes the Strain, Animal, Breeding and Cage data models.
This module stores all data regarding a particular laboratory animal. Information about experimental data and timed matings are stored in the data and timed_matings packages. This module describes the database structure for each data model.
Bases: django.db.models.base.Model
A data model describing a mouse strain.
This is separate from the background of a mouse. For example a ob/ob mouse on a mixed or a black-6 background still have the same strain. The background is defined in the animal and breeding cages. Strain and Strain_slug are required.
Bases: django.db.models.base.Model
A data model describing an animal.
This data model describes a wide variety of parameters of an experimental animal. This model is linked to the Strain and Cage models via 1:1 relationships. If the parentage of a mouse is known, this can be identified (the breeding set may not be clear on this matter). Mice are automatically marked as not alive when a Death date is provided and the object is saved. Strain, Background and Genotype are required field. By default, querysets are ordered first by strain then by MouseID.
Bases: django.db.models.base.Model
This data model stores information about a particular breeding set
A breeding set may contain one ore more males and females and must be defined via the progeny strain. For example, in the case of generating a new strain, the strain indicates the new strain not the parental strains. A breeding cage is defined as one male with one or more females. If the breeding set is part of a timed mating experiment, then Timed_Mating must be selected. Breeding cages are automatically inactivated upon saving when a End date is provided. The only required field is Strain. By default, querysets are ordered by Strain, then Start.
Admin site settings for the animal app.
Bases: django.contrib.admin.options.ModelAdmin
Provides parameters for animal objects within the admin interface.
An admin action for marking several animals as sacrificed.
This action sets the selected animals as Alive=False, Death=today and Cause_of_Death as sacrificed. To use other paramters, mice muse be individually marked as sacrificed. This admin action also shows as the output the number of mice sacrificed.
Bases: django.contrib.admin.options.TabularInline
Provides an inline tabular formset for animal objects.
Currently used with the breeding admin page.
alias of Animal
Bases: django.contrib.admin.options.ModelAdmin
Settings in the admin interface for dealing with Breeding objects.
This interface also includes an form for adding objects associated with this breeding cage.
An admin action for marking several cages as inactive.
This action sets the selected cages as Active=False and Death=today. This admin action also shows as the output the number of mice sacrificed.
This file contains tests for the animal application.
These tests will verify generation and function of a new breeding, strain and animal object.
Bases: django.test.testcases.TestCase
Tests the model attributes of Animal objects contained in the animal app.
Instantiate the test client.
Depopulate created model instances from test database.
This is a test for creating a new animal object, with only the minimum fields being entered. It then tests that the correct unicode representation is being generated.
This is a test for creating a new animal object, with only the minimum fields being entered
Bases: django.test.testcases.TestCase
Tests the model attributes of Breeding objects contained in the animal app.
Instantiate the test client.
Depopulate created model instances from test database.
This is a test for creating a new breeding object, with only the minimum being entered. That object is then tested for the active state being automatically set when a End date is specified.
This is a test for creating a new breeding object, with only the minimum being entered.
This test verifies that the absolute url of a breeding object is set correctly.
This is a test for the unweaned animal list. It creates several animals for a breeding object and tests that they are tagged as unweaned. They are then weaned and retested to be tagged as not unweaned. This test is incomplete.
Bases: django.test.testcases.TestCase
These are tests for views based on Breeding objects. Included are tests for breeding list (active and all), details, create, update and delete pages as well as for the timed mating lists.
This test checks the view which displays a breeding edit page. It checks for the correct templates and status code.
This test checks the view which displays a breeding detail page. It checks for the correct templates and status code.
This test checks the view which displays a breeding detail page. It checks for the correct templates and status code.
This test checks the view which displays a breeding list page. It checks for the correct templates and status code.
This test checks the view which displays a breeding list page, for all the cages. It checks for the correct templates and status code.
This test checks the view which displays a new breeding page. It checks for the correct templates and status code.
This test checks the view which displays a breeding list page, for all the cages. It checks for the correct templates and status code.
This package defines the timed_mating app.
Timed matings are a specific type of breeding set. Generally, for these experiments a mating cage is set up and pregnancy is defined by a plug event. Based on this information, the age of an embryo can be estimated. When a breeding cage is defined, one option is to set this cage as a timed mating cage (ie Timed_Mating=True). If this is the case, then a plug event can be registered and recorded for this mating set. If the mother gives birth then this cage is implicitly set as a normal breeding cage.
This defines the data model for the timed_mating app.
Currently the only data model is for PlugEvents.
Bases: django.db.models.base.Model
This defines the model for PlugEvents.
A PlugEvent requires a date. All other fields are optional. Upon observation of a plug event, the PlugDate, Breeding Cage, Femalem, Male, Researcher and Notes can be set. Upon sacrifice of the mother, then genotyped alive and dead embryos can be entered, along with the SacrificeDate, Researcher and Notes.
Bases: django.core.exceptions.ObjectDoesNotExist
Bases: django.core.exceptions.MultipleObjectsReturned
Over-rides the default save function for PlugEvents.
If a sacrifice date is set for an object in this model, then Active is set to False.
Bases: django.db.models.base.Model
This defines the model for PlugEvents.
A PlugEvent requires a date. All other fields are optional. Upon observation of a plug event, the PlugDate, Breeding Cage, Femalem, Male, Researcher and Notes can be set. Upon sacrifice of the mother, then genotyped alive and dead embryos can be entered, along with the SacrificeDate, Researcher and Notes.
This package describes forms used by the Timed Mating app.
Bases: django.forms.models.ModelForm
This form is used to enter Plug Events from a specific breeding cage.
This package defines custom views for the timed_mating application.
Currently all views are generic CRUD views except for the view in which a plug event is defined from a breeding cage.
This view defines a form for adding new plug events from a breeding cage.
This form requires a breeding_id from a breeding set and restricts the PlugFemale and PlugMale to animals that are defined in that breeding cage.
This urlconf sets the directions for the timed_mating app.
It comprises of create, update, delete, detail and list of plug events.
Settings to control the admin interface for the timed_mating app.
This file defines a PlugEventsAdmin object to enter parameters about individual plug events/
This file contains tests for the timed_mating application.
These tests will verify generation of a new PlugEvent object.
Bases: django.test.testcases.TestCase
Test the models contained in the ‘timed_mating’ app.
Instantiate the test client. Creates a test user.
Depopulate created model instances from test database.
This is a test for creating a new PlugEvent object, with only the minimum being entered.
This is a test for creating a new PlugEvent object.
This test uses a Breeding, PlugDate, PlugMale and PlugFemale field.
This is a test for the automatic inactivation of a cage when the SacrificeDate is entered.
Bases: django.test.testcases.TestCase
Test the views contained in the ‘timed_mating’ app.
Instantiate the test client. Creates a test user.
Depopulate created model instances from test database.
This tests the plugevent-delete view, ensuring that templates are loaded correctly.
This view uses a user with superuser permissions so does not test the permission levels for this view.
This tests the plugevent-detail view, ensuring that templates are loaded correctly.
This view uses a user with superuser permissions so does not test the permission levels for this view.
This tests the plugevent-edit view, ensuring that templates are loaded correctly.
This view uses a user with superuser permissions so does not test the permission levels for this view.
This tests the plugevent-list view, ensuring that templates are loaded correctly.
This view uses a user with superuser permissions so does not test the permission levels for this view.
This tests the plugevent-new view, ensuring that templates are loaded correctly.
This view uses a user with superuser permissions so does not test the permission levels for this view.
This tests the plugevent-new view, ensuring that templates are loaded correctly.
This view uses a user with superuser permissions so does not test the permission levels for this view.
This package defines the Group application. This app defines generic Group and License information for a particular installation of MouseDB. Because every page on this site identifies both the Group and data restrictions, at a minimum, group information must be provided upon installation (see installation instructions).
Bases: django.db.models.base.Model
This defines the data structure for the Group model.
The only required field is group. All other fields (group_slug, group_url, license, contact_title, contact_first, contact_last and contact_email) are optional.
Bases: django.core.exceptions.ObjectDoesNotExist
Bases: django.core.exceptions.MultipleObjectsReturned
Bases: django.db.models.base.Model
This defines the data structure for the License model.
The only required field is license. If the contents of this installation are being made available using some licencing criteria this can either be defined in the notes field, or in an external website.
Bases: django.core.exceptions.ObjectDoesNotExist
Bases: django.core.exceptions.MultipleObjectsReturned
Bases: django.db.models.base.Model
This defines the data structure for the Group model.
The only required field is group. All other fields (group_slug, group_url, license, contact_title, contact_first, contact_last and contact_email) are optional.
This file contains tests for the groups application.
These tests will verify generation of a new group and license object.
Bases: django.test.testcases.TestCase
Test the models contained in the ‘groups’ app.
Instantiate the test client.
Depopulate created model instances from test database.
This is a test for creating a new group object, with all fields being entered, except license.
This is a test for creating a new group object, with only the minimum being entered.
This is a test for creating a new license object, with all fields being entered.
This is a test for creating a new license object, with only the minimum being entered.