New lists functionality - solution for stubs and Florula

[RobinaSanderson]

This idea came about from attempting to find a solution for 2 main issues:

1. being able to generate a placeholder or stub for named taxa that do not yet have profiles (collection master list)
2. being able to define a list of taxa to apply eFlora functions (where the list could be generated by doing a geographical search in ALA)

The collection administrator needs to be able to define a list names from which to create profiles for their collection. For eFlora of Australia this list needs to:

• accommodate utilising the names from APNI and APC via the NSL feed (this feed will include names used for stubs)
• allow the collection administrator to create names which may either match to APNI/APC names or remain unmatched. The list will then be used when searching for profiles either for reference or for creating and updating profiles.

In addition, an eFlora user needs to be able to enter a list of taxa to limit the eFlora's search, keys and other functions.

• maintain ability for a collection to work without a list selected (ie: current functionality)
  • if this is the case the filter option on the home page and in the header menu needs to be removed
• selection of a default list in 'Collection Settings'. This list would be selected from lists in the ALA list service. Note: the ALA list service may need a new list type e.g. "Profile list"
• integration with search and any functionality where the current 'internal' list of profiles is used (ie: search ALA & NSL potentials through external list instead of internal list of profiles) see #412
  • essentially inserts an extra step to 'search' external list (need to ensure this 'external search' functions in exactly the same way as 'internal search')
  • internal list is only used to 'retrieve' a profile for display (and determine if stub needs to be generated)
• auto-stub generation for any name on 'external list' but not 'internal list', includes:
  • removal of "create new profile button" where list is being used
  • ability for editors to 'convert' stub into a profile and begin editing (need to be able to handle the ‘cancel’ option, ie: profile is not saved)
• filtering of all components (search results, keybase keys, etc) to only names on external list see #412
  • ie: allows florula
• selection of an alternate list (and ability to revert back to default list) on home page see #412
  • includes prominent display of which list is 'active'
• Access control… who is allowed to edit the ‘master/default’ list for a collection in the List service?Collection Admin and ALA Admin

Where list functionality is implemented, the "Add new profile" button should be removed from the display for those with editing privileges as new profiles would be added via the list.

Question:

1. Do we generate DOIs for anything that might be affected by this functionality? think the answer is that it won't affect DOI functionality
2. We made need to cache the master list to improve performance?

[ChrisPalmer1]

High priority

[RobinaSanderson]

Hi @m-hope and @sbearcsiro I have included the requirement that new profiles will be created via the list, therefore, the "Add New Profile button should be removed from the UI.

[Michael: 13/02/18] - note a new issue for this problem has been created: #590.

[m-hope]

@sbearcsiro , I was playing around with the Masterlist functionality and the ability to turn it off once a masterlist has been selected... I noticed that in the current profiles-dev environment, if you select the option "-- No master list --" when a masterlist has previously been selected, the "Sync now" and "Regen stubs" buttons remain greyed out after you've saved the list change... which means that you can't remove the auto-generated stubs. I suspect that greying out those buttons is sensible, but we do need an ability to turn off the masterlist and go back to original functionality if required... not sure the best way to do this??

[Michael: 13/02/18] - Note a new issue for this problem has been created: #582 and is currently in Code Review.