March 2nd, 2012

Present: Jonathan, Danny, Paul, Kirsta, Ben

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
• CHALLENGE: 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.
• POSSIBLE APPROACH: 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, but could possibly run scripts to update these statements.
• WHAT BEHAVIOR CAN WE ASSUME? Setting objects to public will override any other setting (for objects in multiple collections)? need to think through security in multiple collections. For security - responsibility for administrators to understand the implications - need to be able to give admin for a collection? Need to talk about this further.
• ADDITIONAL CHALLENGES: batch object security management, and access to the RELS-EXT stream. If we will have interface functions for changing RELS-EXT, we want to make sure that we are protecting security RDF statements.

Action Items

• Jonathan to continue considering options for FESL based security using RDF statements in RELS-EXT, and will take another look at Surrogates.