New module: Islandora Managed Access

[Bryan Brown]

Hi all,

We've been working on a few modules here at FSU Libraries so that the output of a project we've been working on can live in Islandora. The first of those modules is now complete-ish (is any module ever truly complete?) and ready for feedback from the community. You can find it on GitHub at https://github.com/fsulib/islandora_managed_access, and see a short demo of how it works on YouTube at https://youtu.be/Oer2fRvhGsM.

In a nutshell, it allows for you to put certain objects behind a log-in wall without suppressing them from searching & browsing, and when a user tries to access one of these objects they get an explanation of why the object is restricted and a prompt to register an account with extra info that copyright holders/grant funders would need to know. All that data gets stored for later viewing on the backend. There are options for whitelisted IP ranges and automatic deletion of these users as well. Could be useful in a digital archive where copyright is an issue, or in an IR where there's sensitive data around.

Bryan Brown

FSU Libraries

[Jennifer Eustis]

Thanks for sharing this Bryan. This looks really fantastic. I can see that some in our community using this type of functionality. Have you ever thought of extending the functionality to allow for users to just request a copy of the resource when the content owners don't want that resource to be displayed in addition to providing a user account?

Jennifer

[Bryan Brown]

Hi Jennifer,

Typically if an organization/estate doesn't want materials to be publicly accessible, then they REALLY don't want people to have their own copies (this has been our experience at least). In fact, finding a way to disable any kind of downloading of an object's assets was proposed as part of the spec in the beginning, but due to the way the web works, if you can see an image in your browser it means you already have a copy :)

Despite my personal desire to make everything as open as possible, this module was developed so that we would be allowed to put things in the repository that we wouldn't have been able to otherwise. Since our goal is legal compliance and/or avoiding lawsuits, we've been a bit more conservative in our designs than we normally would be. 

Despite all this, if we can find use cases where an org/estate wouldn't want materials to be viewable but they would be okay with them being downloadable, we could have a discussion about how to fold that functionality in to whats already there.

-Bryan

[Bryan Brown]

Hi Jennifer,

Typically if an organization/estate doesn't want materials to be publicly accessible, then they REALLY don't want people to have their own copies (this has been our experience at least). In fact, finding a way to disable any kind of downloading of an object's assets was proposed as part of the spec in the beginning, but due to the way the web works, if you can see an image in your browser it means you already have a copy :)

Despite my personal desire to make everything as open as possible, this module was developed so that we would be allowed to put things in the repository that we wouldn't have been able to otherwise. Since our goal is legal compliance and/or avoiding lawsuits, we've been a bit more conservative in our designs than we normally would be. 

Despite all this, if we can find use cases where an org/estate wouldn't want materials to be viewable but they would be okay with them being downloadable, we could have a discussion about how to fold that functionality in to whats already there.

-Bryan

On Tuesday, November 8, 2016 at 8:37:30 AM UTC-5, Jennifer Eustis wrote:

[Scott Ziegler]

Bryan,

Thanks for sharing this!

We deal with cultural sensitivity issues, and this could be perfect for us. Additionally, our use case is such that we DO want folks to download content if they're from the community that is represented in the collection. As such, we could definitely put to use any additional functionality that would allow that.

Thanks again!

Best,

Scott

--------------------
Scott Ziegler, MA, MSLIS, CA
Head of Technology
American Philosophical Society
105 South 5th Street
Philadelphia, PA 19106
Telephone: 215.599.4299
Email: szie...@amphilsoc.org

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/islandora.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/ba35a8a7-fa37-478f-bdb9-4b0c3a7046fc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Bryan Brown]

Scott & Jennifer, 

I don't want to come across as obtuse, but I'm still having a difficult time understanding why you would want something to be restricted yet downloadable. Obviously I'm missing something since we now have two people asking for this functionality, but I'm not sure that the listserv is the appropriate place to discuss this.

I've created an issue for discussing this on the module's GitHub repo (https://github.com/fsulib/islandora_managed_access/issues/4), and I'd love for this discussion to continue there so I can wrap my head around it. I'm 100% in favor of extending the module to do these things if it provides value to you! Other folks are also welcome to chime in with their use cases.

-Bryan

To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.

Visit this group at https://groups.google.com/group/islandora.

[Jennifer Eustis]

Hi all,

Currently, all of our content is available and downloadable. There are exceptions where some digital assets have been embargoed. We have 2 scenarios where your module could be adapted. One is that certain digital objects because of the stipulations of the terms under which it was gifted/donated/etc. that the object has to be embargoed. This is something we do for a small exception of objects. Currently, users are unaware of this. This module could be extended to provide an explanation on why the digital asset has been embargoed, when it will go off embargo, and provide a link to contact someone for more information. We would rather provide a way to email a contact rather than create a user account as users would access these objects on our presentation site. Our other scenario is that many participants have requested a way to provide more information about an object in terms of rights and a contact information and may or may not be viewed only when logged in. 

In thinking through this, I think we're looking for a module that detects embargoed objects and displays a message that displays why it is embargoed, when the embargo ends, and who to contact. I'm not sure embargo is the correct term either as this really isn't an embargo on the whole object but the OBJ datastream (?). Whether you use embargo or not, it is allowing the choice to apply a restriction which we don't encourage.

Jennifer