| | 2 | |
| | 3 | We will try a new approach this time. The intention is to keep the `BioPlateEvent` item as generic as possible. Then, it is up to the gui to define what an event really is. This way almost any action could be registered as an event. Under some circumstances we could even let a batch import generate an event. The design idea for the core goes something like this: |
| | 4 | |
| | 5 | * A new item `BioPlateEvent` is created. It should be a `CommonItem` which means it has an owner, name and description, and that it can be shared. The event should also have event-date, entry-date, protocol and hardware properties (eg. similar to `BioMaterialEvent`). |
| | 6 | * The `BioPlateEvent` has a many-to-many association with `BioPlate` which point to the plates that are part of the event. The association is tagged with a "role" attribute which is a text description of what part the plate has in the event. Eg. "source" or "destination" in a move or a child biomaterial creation event. The role names are not dictated by the core. Each actual implementation may choose suitable and human-understandable names. |
| | 7 | * The existing `BioMaterialEvent` items should get a many-to-one link to the `BioPlateEvent` which allows us to keep better track of biomaterial creation events. |
| | 8 | |
| | 9 | |
| | 10 | I'll also want to limit this ticket to the implementation of the core support for events. This includes changes in the web interface for viewing event information. Separate ticket should be created for the actual creation of events. Here is a list of such tickets: |
| | 11 | |
| | 12 | * To do |
