Drupal web form for setup of app terms

[DavidRoy]

We currently use a shared datasheet to handle the content types we should set-up on the FIT Count site. This would be more efficient to handle in Drupal, with where users of a specific role could access and create the content for new countries.

We would need content types to represent a Habitat, Flower, Insect and Insect-Photo.

eg. a Flower content entry would be a page that allows entering: • habitat id • warehouse id • habitat type • sort order number
• common name • scientific name • country codes - allow to select multiple countries this flower applies to.

These entries could then be programmatically imported into the app. @kazlauskis @andrewvanbreda to discuss the requirement @andrewvanbreda to implement

[andrewvanbreda]

Hi @kazlauskis ,

Just having a quick look at what is written here.

I could perhaps write a very long post detailing this. However I think without wanting to complicate matters to start with, if I ask just one question to begin (I think actually it touches on things we have already discussed)

This kind of new Drupal management area would have to store the changes to the data in the Warehouse. Could your app ever be changed in such a way that it reads all the data it needs from the Warehouse?, or would you want an export spreadsheet of what is in the Warehouse to read in?

Let me know if you have any other thoughts regarding David's requirement. After you respond I will post some of my other thoughts.

[DavidRoy]

@andrewvanbreda I agree that full integration with the warehouse would be ideal, but I think we can start by getting the drupal form setup with an export option. The issue text came from @kazlauskis btw!

[kazlauskis]

@andrewvanbreda I agree with David, the species texts don't need to be linked to the warehouse. We currently use a spreadsheet to organise the texts but it would be much more streamlined to use some CMS like Drupal.

[andrewvanbreda]

@DavidRoy @kazlauskis OK. Although it doesn't actually necesserily make it easier to program because it means storing existing data structures in the Drupal database afresh. I suppose what I could do is have a import/export button which just import/exports to external file without storing in Drupal. Although this leaves the problem the Warehouse data structures that already exist will not get updated (although this is a problem we already have). I actually still haven't got around to putting the page live on the FIT Count Site which allows app data editing, but the termlsits, countries do exist in the Warehouse. It will be a problem if those don't get updated inline with changes people are making in Drupal. The other thing to note is that by not linking to the Warehouse we miss out on the user interfaces we already have in Indicia for some of this, there is already Drupal taxon editing. Feel free to comment further while I think.

[DavidRoy]

@andrewvanbreda in that case, it sounds like you are part way through the warehouse link and it makes sense to complete that task?

[kazlauskis]

Sorry, I wasn't following the current work on linking attributes to the warehouse, so I might need to understand how this is connected. I would suggest keeping it simple for this specific task and not linking any of this to the warehouse. We need a few custom content types that certain Drupal users can create and edit. These would contain texts, numbers and photos. The app could then use the standard Drupal API to fetch all of that programmatically.

https://www.youtube.com/watch?v=bb10eGT5YfE

[andrewvanbreda]

@DavidRoy @kazlauskis OK, thanks for the video, I will have a look. I cannot program this in the short term anyway because of workload (unless David indicates this as urgent), but yes I will keep this simple as possible when I do. It is a bit of confusing situation as the species editing does work from Drupal, termlists not at all. So I suspect the best way forward will be to write something that exports to a file, but can be extended to the Warehouse as appropriate. I think actually in the long run, Drupal term editing for Indicia would be useful for many projects and is a goal worth working towards eventually.

[kazlauskis]

This isn't particularly urgent. The two main problems we're trying to solve here are: a) the growing app datasheet can be error-prone to maintain centrally, and merging large sheets can be difficult. It is much better if country partners themselves could create the app content, and b) at the moment, species photos and texts are held separately, which can lead to problems like missing files or mismatched file names, wrong resolutions etc.

We currently use a separate document with instructions on how to compile the info. The ideal scenario, from my perspective, would be to allow a country partner to enter this information using web forms that would enforce the formatting, cross-link between different types (e.g. species-photo entities linked to the correct species entities), also show help texts and suggestions inline the forms. Ideally, the collected photos would be cropped and resized to fixed resolutions.

[andrewvanbreda]

@kazlauskis Thanks, that is very useful description, so we know exactly the aims of what we want the forms to do.

[andrewvanbreda]

AVB: Note to myself so don't forget, once this screen is created and the terms are up to date, the following change can be made to this screen (accessed through the FIT Count website My Results page) https://fitcount.ceh.ac.uk/enter-fit-count

• Remove @disableFiltering=true option from the limit_termlists_and_species_to_selected_location extension.

• Remove th @extraParams={"orderby":"term"} option from both the [smpAttr:1048] and [smpAttr:1050] attributes

[kitenetter]

Not sure if this is still a priority but keeping on the feature request list.

[andrewvanbreda]

Hi @kitenetter It is still on my task list, but is unlikely to be high up my task list anytime soon unless I am told otherwise.