Closed nhurleywalker closed 6 months ago
In the Rating model we have the following options for the candidate types:
CAND_TYPE_CHOICES = (
(T, "Transient"),
(AP, "Airplane"),
(RFI, "RFI"),
(SL, "Sidelobe"),
(A, "Alias"),
(CC, "CHG Centre"),
(S, "Scintillation"),
(P, "Pulsar"),
(AGN, "AGN"),
(D, "Drift"),
(BF, "Bad Frame"),
(O, "Other"),
)
The abbreviations and descriptions can be updated, delete, expanded, and we can have some reserved "ex1, ... , ex2" types that the user can define via the app.
This might be overkill, but if these choices are turned into a bona fide model, then we (i.e. Natasha and I) can grow and shrink the list ourselves without needing to deal with any more migrations in the future. More effort now, less effort later.
Good idea, that would be much nicer than the categories of ex1... ex2 that I suggested earlier.
I'll make a todo:
In branch 24-custom-candidates
the list of candidate classification options has been turned into a model called Classification
, which works much like the Project
tag that was added to the candidates table (see #22/#28).
Users can create/edit/delete Classification labels using the admin
interface. Each classification has a (unique) name and a description. The name is what is displayed through most of the app, and it is recommended that this name be short to avoid strangely wide drop down menus.
Currently the classifications are not bound to a project (they are "global"), but it is possible to set this up if it is required.
I need to state what classes should continue to exist, and which ones can be deleted.