Improve list view and fix old web-kadi issue

taldcroft commented 2 years ago

Description

Fix the old issue https://github.com/sot/web-kadi/issues/2. The problem was that the template expects the first field to be the primary key. This PR takes the approach of just changing the field order to make that the case for Orbit events.

It also addresses the request to reverse the time order. This is done for all event types, which seems reasonable to me.

Lastly, this PR adds localhost to the ALLOWED_HOSTS list because the local server doesn't work without that.

Note: this is based on eed97c1 (Merge pull request #204 from sot/note-bad-dump) which is the commit before #202 that breaks using the local server.

Testing

[x] Passes unit tests on MacOS, linux, Windows (at least one required)
[x] Functional testing

Functional testing

Ran a local server and verified that Orbit events can be selected from the list view and properly displayed in detail view.
Confirmed that the sort order is reversed in all event types.

Fixes https://github.com/sot/web-kadi/issues/2

javierggt commented 2 years ago

It seems ok to me. My main question is about process.

Will this change require a DB migration? because you changed the order of fields in the DB. How do you suggest we do the test then? I guess we have to:

replicate $SKA/data/kadi (currently the test server runs directly on $SKA/data/kadi)
Update in test environment
Apply migrations there
test

And that leads to the question of "should the test server ever run on $SKA/data"? Do we need to change something in processing for this?

taldcroft commented 2 years ago

Good question about the DB and possible migration. I assumed that since it works with the existing DB that all is OK. But I didn't try adding new data. It's actually not too long to regenerate the entire events database. In the end there is just the events3.db3 file that we can copy where needed. I'll think more on it.

taldcroft commented 2 years ago

@javierggt - given the good question about the mis-ordering between the database fields and the model definition fields, I decided to dig in a bit and figure out a better way. This now just keeps track of the primary key column index and uses that in the template to make the detail view link.

This has the unfortunate feature of using the "private" model _meta attribute, but this is already used in other bits and if this part of the Django API every changes we will certainly notice it in functional testing.

sot / kadi