Ivan,
Thank you for the encouragement to take a look at the java code. I think I
found a simple solution which I will submit as a pull request.
The XSLT code changes that take advantage of this data are a bit messy, and
I am not certain that they would be applicable for others.
1, Set <xsl:variable name="AUTH"
select="/dri:document/dri:meta/dri:userMeta/@authenticated"/>
2. Modify externalMetadataURL
<xsl:variable name="externalMetadataURL"
select="concat('cocoon://metadata/handle/',$handle,'/mets.xml?rightsMDTypes=METSRIGHTS')"/>
3. Query the mets rights. My logic assumes that a thumbnail should be
displayed (1) if the item is publicly available OR (2) the item is
available to my registered users AND the user is logged in. My hope is
that this will significantly reduce the occurrences in which a user is
redirected to a thumbnail on login.
<xsl:when
test="$context/mets:fileSec/mets:fileGrp[@USE='THUMBNAIL']/
mets:file[@GROUPID=current()/@GROUPID]">
<xsl:variable name="authid"
select="$context/mets:fileSec/mets:fileGrp[@USE='THUMBNAIL']/mets:file/@ADMID"/>
<xsl:variable name="thumbauth"
select="//mets:rightsMD[@ID=$authid]"/>
<xsl:variable name="angrec"
select="$thumbauth//metsrights:Context[@CONTEXTCLASS='MANAGED
GRP'][metsrights:UserName[text()=$GUCOMM]]"/>
<xsl:variable name="pubrec"
select="$thumbauth//metsrights:Context[@CONTEXTCLASS='GENERAL PUBLIC']"/>
<xsl:choose>
<xsl:when test="($angrec and $AUTH='yes') or
($pubrec)">
<a class="image-link">
<xsl:attribute name="href">
<xsl:value-of
select="mets:FLocat[@LOCTYPE='URL']/@xlink:href"/>
</xsl:attribute>
<img alt="Thumbnail">
<xsl:attribute name="src">
<xsl:value-of
select="$context/mets:fileSec/mets:fileGrp[@USE='THUMBNAIL']/
mets:file[@GROUPID=current()/@GROUPID]/mets:FLocat[@LOCTYPE='URL']/@xlink:href"/>
</xsl:attribute>
</img>
</a>
</xsl:when>
<xsl:otherwise>--</xsl:otherwise>
</xsl:choose>
</xsl:when>
Thank you again for your help!
Terry
On Mon, Sep 30, 2013 at 6:15 PM, helix84 <[email protected]> wrote:
> Hi Terry,
>
> you're right, that information is not there. Arguably, it should, since we
> have all the other permissions information there. The reason it isn't is
> that simple embargo (embargo expressed as time-based resource policies) was
> a new feature in 3.0. One more similar omission is that this information is
> missing from the AIP export (because it requires changes to the AIP file
> format). I don't think @mire plans to work on this in the little time that
> is left for 4.0, but if you would add it, I'd support accepting it to
> DSpace. The contribution deadline is October 7 - a pull request would have
> to be opened by then.
>
> To add it, you would have to do some modifications to Java code. They seem
> rather simple. Take a look at this method which generates the relevant part
> of the METS file [1]. Also take a look at the signature of the
> ResourcePolicy class here [2], especially the getStartDate()
> and getEndDate() methods.
>
> [1]
> https://github.com/DSpace/DSpace/blob/dspace-3.2/dspace-api/src/main/java/org/dspace/content/crosswalk/METSRightsCrosswalk.java#L249
> [2] http://demo.dspace.org/javadocs/3/apidocs/
>
>
> Regards,
> ~~helix84
>
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
>
--
Terry Brady
Applications Programmer Analyst
Lauinger Information Technology
202-687-7053
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
