Closed andrewvanbreda closed 1 year ago
@sacrevert Hi Oli, There is a bit too much here for me to think about all at once I think. So I will just consider one element as a starting point. Here in the "Plot level information" section is a description of several attributes, but these would go onto the Plot Maintenance/Editing page. So this leaves the question, is the Plot Maintenance/Editing page going to vary depending on the project type also, or are these plot attributes relevant to both project types?
Hi @andrewvanbreda Yes, these attributes are only relevant to Standard plots, so they would be slightly different attributes to the NPMS type (and true NPMS) plots (although of course some things are in common)
@sacrevert Um, ok will need to have a think about how to get this to work. Maybe one plot maintenance page which hides different attributes depending on the project type. Will let you know
Here are the NVC data. It would be good if, ultimately, there were two options, one to select the community and one to select the sub-community if required. The selection of the community would then automatically filter the subcommunities to show only those nested within the community. (Kind of like the data entry for NPMS, where the fine habitat selection box only appears once you have selected the broad habitat)
The selection boxes could just list the codes for brevity, but perhaps the full name could appear somewhere once the code has been selected (e.g. in grey beneath the selection box?) NVC_community_names.zip
And here is the other abundance scale that I mentioned (Braun-Blanquet is the name) BBscale.zip
Also allow Presence/absence as another, simple, "abundance" scale
@sacrevert Hi Oli,
Just looking at this, I noticed the sub-community parent "MG7" doesn't have an entry in the main communities list
Ah, well spotted. It should have I think
@sacrevert Alas I cannot take the credit, it was just when I did a test import into the dev warehouse it complained :)
AVB: Note for myself. The NVC community data can be imported into a termlist using the code as the term, the name can be a synonym. A second import can then be done with the sub-communities using the main community term (the code) mapped to the parent, again using the sub-community name as a synonym.
This can then be mapped on a lockup attribute with the control type set to by a hierarchical drop-down.
The main form will then need an onChange handler to detect the change to the drop-down by the user, and this then displays the full name synonym from the database.
There is a test term list not he dev warehouse, although it does have mistakes in it because it is a test.
Hi @andrewvanbreda I list some outstanding things based on my document below:
Hi @sacrevert I imported the communities on my machine, is the kind of thing in the screenshots ok (ignore the tab name I am using as it will go on Habitats tab. Also ignore lack of space between the two drop-downs which we can fix with a style sheet).
I included the fulls names, as limiting to just the code, then displaying the full name in a separate box is quite a bit more problematic to do. Let me know if you think that is necessary.
In particular if you could confirm that the format of -
Looks good to me @andrewvanbreda I assume one doesnt have to select a nested type. (Some communities don't have nested types, and even where they do it may be that the user did not determine it).
@sacrevert Yes some entries do not have a sub-community anyway. We can have it so that the sub-community is optional even if it is present.
Be aware some subcommunities are the same as the parent. So we can have the situation as per this screenshot
This is correct as per the supplied spreadsheet, but we could remove the sub-comminity in this situation if you wanted, then the user could just select the parent
It would be clearer to remove the subcommunity in this situation if possible and not too time-consuming for you @andrewvanbreda
@sacrevert Shouldn't be. I will just do that by simply manually removing those particular rows from the sub-communities sheet before the import, just leaves the parent.
@sacrevert Community now available on Habitat tab here. https://plantportal.ceh.ac.uk/standard-mode-data-entry
Note I haven't altered CSS yet to put a gap between the two drop-downs, but the rest should be ok.
Hi @BirenRathod, Would you be able to pull the Plant Portal reports folder whenever you get a sec please. Thanks
@andrewvanbreda Reports have gone live now.
@BirenRathod Perfect thanks :)
Hi @BirenRathod If you get a chance, would you be able to pull the Plant Portal reports folder please, cheers.
@andrewvanbreda That's done.
@BirenRathod Brilliant thanks :)
Hi @BirenRathod If you get a second, would you be able to pull the Plant Portal reports folder again please. Thanks
@andrewvanbreda Which report are you after? I just pulled again the report folder after John did and I don't see any changes in the plant_portal folder. The last changed was done on the 26th.
@BirenRathod Thanks Biren, I just noticed you are right, the push had failed. I pushed it now. The change was in get_plots_for_plot_group_id, although I thought they had been previous changes since 26th, but may be wrong about that. No rush.
@andrewvanbreda that report has gone live now.
Closing this, as have put live a fix that was stopping the plot populating in edit mode (actually same problem as this in NPMS) https://github.com/BiologicalRecordsCentre/NPMS/issues/287
From Oli standardPpFields_v0.docx
"Andy, here is my outline for the data entry form templates for standard mode. There is a fair bit to accommodate for the general sample page, so I wonder whether we could group these into expandable sections, the less important ones being collapsed by default. Let me know where you have questions -- would be happy to have a web meeting if anything needs discussing."