dchandekstark

ActiveFedora::Base.class_eval do

  # method_missing is defined, so adding methods                                                                                                        

  def auditable?
    begin
      self.is_a? ActiveFedora::Auditable
    rescue
      false
    end

dchandekstark

ACTIVE = 'A'
INACTIVE = 'I'
DELETED = 'D'

def active?
  dsState == ACTIVE
end

def inactive?
  dsState == INACTIVE

dchandekstark

Grant

grant [permission], to: [grantees] -> result

Arguments

permission - Symbol (required) - one of [:discover|:read|:edit]

dchandekstark

def get_objects_for_solr_field_values(solr_field, values, opts = {})
  extra_solr_params = opts.delete(:extra_solr_params) || {}
  documents = get_solr_response_for_field_values(solr_field, values, extra_solr_params)[1]
  method = opts.delete(:lazy) ? :lazy_reify_solr_results : :reify_solr_results
  ActiveFedora::SolrService.send(method, documents, opts)
end

dchandekstark

class HasContentValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    unless value.has_content?
      record.errors[attribute] << "The \"#{value.dsid}\" datastream does not have content"
    end
  end
end

dchandekstark

Hydra Roles for Users and Groups

Why

Hydra's current authorization model accounts for user- and group-based permissions (what I am calling groups are sometimes in Hydra called "roles", such as in the RoleMapper class or hydra-role-management). Authorization data is stored in the repository (as rightsMetadata or policy-based defaultRights) and provides a simple set of permissions ("discover", "read", and "edit") which are applied atomically at the object level. Adding other kinds of permissions (such as the ability to add child objects to a parent) or ones that don't depend on repository data (such as the ability to create new objects) involves custom coding using the current authorization library (CanCan, or CanCanCan in hydra-head 7).

It would seem beneficial to the Hydra community and/or individual adopters to explore the possibility of a common approach to extending Hydra's native authorization API.

What

dchandekstark

class Foo < ActiveRecord::Base
  belongs_to_af :bar
end

class Bar < ActiveFedora::Base
  has_many_ar :foos
end

dchandekstark

Manager

dchandekstark

  CHUNK = 1024**2
  
  def add_file(file, dsid, file_name)
    return add_external_file(file, file_name) if dsid == 'content'
    super
  end

  def add_external_file(file, original_filename)
    external_file_path = generate_external_file_path

dchandekstark

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF [
    <!ENTITY rdfns 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
    <!ENTITY rdfsns 'http://www.w3.org/2000/01/rdf-schema#'>
    <!ENTITY dcns 'http://purl.org/dc/elements/1.1/'>
    <!ENTITY dctermsns 'http://purl.org/dc/terms/'>
    <!ENTITY dctypens 'http://purl.org/dc/dcmitype/'>
    <!ENTITY dcamns 'http://purl.org/dc/dcam/'>
    <!ENTITY skosns 'http://www.w3.org/2004/02/skos/core#'>
    <!ENTITY owlns 'http://www.w3.org/2002/07/owl#'>