Add DB models & views for fitting specifications#222
Conversation
This also involved adding a new `create_fittingspec` permission and linking it up in a few unexpected places. Probably some more basic tests are still needed but it's a start.
|
With 9f77284 I'm thinking about how to implement views for fitting specs, initially around creation/upload. I don't want to have to duplicate lots of code and templates from the entities app. But equally some things will be different (like the new spec form having a protocol link) so some overrides will be necessary. I think doing it neatly will need some alterations to the generic entities views; I'm still thinking about how best to do so. Some will just be stylistic, e.g. adding a 'fitting specs' button alongside models and protocols; making the 'Your fittingspecs' heading decent English! If running this locally you can see what I've implemented this far at http://localhost:8000/fitting/fittingspecs/ More thoughts added to PR description. |
Codecov Report
@@ Coverage Diff @@
## master #222 +/- ##
========================================
- Coverage 95.1% 94.7% -0.5%
========================================
Files 65 65
Lines 2858 2662 -196
Branches 316 280 -36
========================================
- Hits 2720 2522 -198
- Misses 98 100 +2
Partials 40 40
Continue to review full report at Codecov.
|
These let us write nicer templates that generalise to fitting specs.
This now lets us use entity views directly where there are no fitting-specific differences.
It uses the new helpers to filter out invisible protocols
and thereby use the entity views for most fitting views. I don't guarantee I haven't missed some uses in templates; these don't seem to be caught well by our automated testing. Should probably look into that!
From my manual testing, it looks like everything we need is now implemented! Except for automated tests, of course...
|
This needs unit tests to be written for the fitting spec views, but from manual button pressing everything seems to work as expected. So probably worth reviewing and merging, with testing in a separate PR @sroderick-g5sro ? I've updated the description so it explains what was done. |
And moved the list versions / add version links to buttons so we don't just have a single button on its own! (And so the drop-down doesn't mess up spacing.)
|
Note before this is merged: we'll need to merge the latest master in to this branch then do |
|
I've started my review of this, but its going to take me sometime to understand the background of this change and then work through it. I am keen to try and use it from a user's perspective. |
That's expected! I have no meetings this morning, so could do a call to walk you through the user's POV. It's discussed in text form in #135. For this PR, basically it's treating fitting specifications like models & protocols, in that they're versioned collections of files that a user can upload, backed by a git repository. So the same creation/view/etc UI applies. But with slight tweaks because they link to a protocol. Which reminds me - I don't think I've included that protocol link in the detail view yet! Will try to add that today... |
Remove the 'Files' button
And add new fields to fitting spec cache.
|
Just a trivial point that when user is deleting an entity or fitting spec. Get a confirm button but not a cancel one. So have to use browser back. Can't remember if it was always like this - assume so |
|
Sorry about v. minor point - when clicking on model / protocol /etc. you get some "flash of unformatted content" I think this is becuase takes time for the version number and detail to show up. probably not worth worrying about. I've attached a video |
|
I'm not too keen on the way that the "Compare..." button works. It took me a while to figure out that it contained a clickable link. |
Yes, I think that was always the case. A cancel button as well makes sense though!
Yes, that's in the delay while the Javascript code fetches the JSON metadata for the fitting spec and uses it to fill in the remaining page content. We could make the interim page a bit nicer though!
For models & protocols there are at least two links there, which is why it behaves like a drop-down menu on hover. There may be a better way to do it, but that was the best I came up with, without using up too much screen space! |
|
From the fitting specifications "tab" clicking on the name and "add new version" go to the same location. I expected to be presented with a list of files when clicking on the name. (I felt at one point it was doing this). Please see video clip for replication. This is not the same behaviour as for models / protocols / datasets. |
|
That should happen if the original creation process was interrupted, i.e. if the spec was created in the DB but no files were added at the time. (It also happens for models and protocols I believe.) |
|
I get error building site when trying to compare to versions of a fitting spec
|
|
I saw that, but thought I'd fixed |
|
I have tried refreshing gulp and same is still happening. I have also put a couple of minor questions in the review |
|
That's odd, it's working locally. Maybe refresh the page just in case your browser has cached the JS? |
|
I have noticed that the 'click to show single version' feature in the drop-down isn't working once you get to the page though. But then, it's not working for models or protocols either! Edit: that's because |
yes sorry was a caching problem - thanks |
Add DB models & views for fitting specifications
3 participants
Part of #203.
I've managed to generalise the entity views so most can now be used as-is for fitting specifications, for which the
FittingSpecDB model has been added. It inherits fromEntitybut unlike the model & protocol cases has its own table in the DB to hold the protocol link.The only views that have different versions for fitting specs are the following, so they can use different forms:
All the following views are re-used for fitting specs at present. In several cases the templates or views have been adapted so some elements are only used for models/protocols.
The other entity views don't apply to fitting specs, although variations on the first two might when we have fitting results:
To make the reuse work several things were needed:
EntityTypeMixinnow knows aboutFittingSpecurl_typeanddisplay_typefields as well asentity_typeto help with user-friendlinesscurrent_namespacecontext item is available in all templates so URL reversing can tell which app we're currently in (fitting or entities)core/context_processors.py. cf e.g. https://stackoverflow.com/questions/20020911/how-to-get-the-name-of-current-app-within-a-templateselfis a view, useself.request.resolver_match.namespaceto get at it.Other bits of note:
EntityManager.visible_to_userquery for filtering protocols that can be linked to a new fitting spec. Also improvedshared_with_userso it can be combined without using.union(). This will be handy elsewhere too: at least when creating datasets, and possibly in matrix views.For future consideration:
It's similar to DatasetJsonView & ExperimentVersionJsonView (though not quite identical), and parts of ExperimentComparisonJsonView.
There's also overlap with EntityComparisonJsonView.