Small misc improvements and modifications #21
Labels
No labels
Bug
Client: Biosphere Capital
Client: Central Hawkes Bay District Council
Client: Forward Works Viewer
Client: Kea/Kākā Databases
Client: Otorohanga District Council
Stage: Blocked
Stage: Doing
Stage: Peer review / Staging
Stage: Ready
Stage: UAT AT
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lightweight/right-tree#21
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
assigned to @danalambert
marked the checklist item Fix image height for zone selection as completed
mentioned in merge request !18
mentioned in merge request !19
marked the checklist item Add forest position info to results as completed
I'm debating what ways the filter ignores could be implemented. Two ways I'm thinking, one where the logic be stored in the model and one where it is hard-coded as part of the filter logic (in the view - make lists of zones that have ignores). I guess there's advantages and disadvantages of each (keeping logic together in the model and making it user configurable rather than making an arbitrary mapping in filters).
I'm leaning toward putting it as a model field/s (connected to the Zone model), however, then another choice will be if this is going to be one field that contains all filter ignores.
For example the one field would require a foreign key to another model say
FilterIgnoreOptions
to provide a multi select field with defined values, the output would look something like['soil_order', 'eco_region']
.Alternately, we could create multiple fields for each filter ignore for example, we add to Zone model two boolean fields
ignore_soil_order_filter
andignore_location_filter
. This method is easier but less extendable in the future.@alistairmcintyre thoughts?
I think this is why putting all the logic and flow on the backend is a bit gnarly. Creating additional models isn't part of the spec, and we should really try to stick within the parameters we've been given.
Adding boolean fields to the Zone model for now accomplishes the short term goal, while also leaving us open to adjustment in the future (as we can just modify what the api returns if necessary) so I think that's the more pragmatic choice at this stage (and we have to remember that YAGNI exists and we shouldn't over-engineer something when it's not required)
mentioned in merge request !20
marked the checklist item Maori garden - ignore location information as completed
marked the checklist item Add zone specific filter rules (ignoring steps etc...) as completed
Can't complete
Redirect to a different habitat image if such a zone is selected
until we receive updated diagrams.changed the description
mentioned in merge request !22
marked the checklist item Redirect to a different habitat image if such a zone is selected as completed
Have setup the code to handle redirects with a demo, will handle real setup when we receive the proper image diagrams.
marked the checklist item Order plant list by the fields specified in the requirements as completed
mentioned in merge request !23