March 2nd, 2012

Present: Jonathan, Danny, Paul, Kirsta

Agenda

• Views
• Security

Views

• Danny provided a tour of Apache search, views, and the Apache solr views plugin
• Solr Apahe Views is being developed for 7, but 6 is pretty robust. We need to get our data in Apache Solr if we wanted to use Apache Solr Views out of the box (maybe).
• Apache Solr Views 6
• Arguments work much better with Apache Solr plugin, but filters are not as good as default Drupal Views behaviour
• We prefer using request handlers - filtering by namespace prefix will remain an important part of the architecture in seven
• Can we use Views on top of our Solr? Danny will have to look into it. Looks like we would be writing our own plugin for reading Solr, but might need to put in Apache Solr (Drupal) module in as well. Added complexity but could give us a unified search.
• Conclusion: Views integration is not a priority in seven at the moment.

Action Items

• Finish porting Drupal 7 - Danny, Alan, Paul, and Jonathan to discuss how the seven module will be developed and report back to the Roadmap group in the next meeting. Danny will also show Alan the Solr plugin stuff.
• Danny is going to research whether we can use the Apache Solr plugin module to read Islandora Solr indexes.
• NOTE: Integrating Solr indexes is a major priority (Search across Drupal, Fedora, and maybe ILSs)
• Still aiming for the end of March for a beta core (security)

Security

• It doesn't appear we can preserve the AUDIT trail if we don't login as a specific Fedora user. Surrogates in Fedora may be an option, but Jonathan ran out of time this week to take a look. It might be possible, but it doesn't look like it supports FESL. Jonathan to write to the Fedora list. From Paul's perspective, it didn't appear to be an option when he was developing the servlet filter, and he has not working. It's not looking really good for a Fedora that is locked down to a single user (so we are not optimistic about the options for security
• Fesl supports collections, but you can only live in one collection (not multiple collections) so this does not work for us. We could still use Fesl for individual objects, but we wouldn't get inheritance. So this does not offer a great deal.
• RELS-EXT security - Store statements in the RI for each object - who can view it and how, and then have FESL enforce that. We would be abandoning the idea of inheritance from collection. Problems of making security far more manual.
• Setting objects to public will override any other setting (for objects in multiple collections) - need to think through security in multiple collections.