[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20365#action_20365 ] Mark Diggory commented on DS-906: - Seems so... but My position still stands... I really question the code being where it is. For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-829) OAI Extended Addon : Adding filter and modifying capacities to the OAI interface
[ https://jira.duraspace.org/browse/DS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20366#action_20366 ] Robin Taylor commented on DS-829: - Just a wee comment about where we do the filtering. This module would do the filtering on the result set returned by Harvest.harvest(..). The problem with that is that the administrator may have specified that a partial response should contain 100 records, if we filter out records after creating the result set of 100 records we have to take some corrective action to bring the total number back up to 100. The code appears to achieve this by a recursive call to Harvest.harvest(..). Would it not be better to filter out unwanted items whilst creating the result set ? So the filtering would take place in Harvest.harvest(..) ? There is already some filtering done there, depending on configuration both withdrawn items and items with restricted visibility can be excluded from the result set. The calling code could pass an array of filters as part of the call which Harvest could use to exclude items. So in Harvest.harvest... (* Apologies for the pseudo code *) Read database Apply filters If not required then go back and read another item else add to result set OAI Extended Addon : Adding filter and modifying capacities to the OAI interface Key: DS-829 URL: https://jira.duraspace.org/browse/DS-829 Project: DSpace Issue Type: New Feature Components: OAI-PMH Reporter: João Melo Assignee: Robin Taylor Fix For: 1.8.0 Attachments: OAIExtended-v2.2.tar.gz, OAIExtended_v2.1_with_documentation.tar.gz Purpose The OAI Extended Addon was initially developed to allow DSpace to be compliant with the Driver project guidelines (http://www.driver-repository.eu). How it works? When an OAI-PMH request is received, the DSpace database is queried through the standard OAI Interface included in DSpace. After that, the OAI Extended Addon starts to work. First, the list of items retrieved from the database is filtered by a Filter Mechanism, after that, each item associated metadata is modified by a Modifier Mechanism. The results of both actions are returned to the harvester that performed the request. Because of the initial purpose, most of the filters and modifiers implemented are specific to the Driver compliance issue. But there is an easy way to develop your own filters and/or modifiers, just by extending the abstract class Filter and/or Modifier. More information is included in the attachment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Created: (DS-907) COinS not recognized in listings and single item view by Zotero or Citavi
COinS not recognized in listings and single item view by Zotero or Citavi - Key: DS-907 URL: https://jira.duraspace.org/browse/DS-907 Project: DSpace Issue Type: Bug Components: XMLUI Affects Versions: 1.7.1 Reporter: Claudia Jürgen Priority: Major Just noted that in DSpace 1.7.1 XMLUI Mirage theme the COinS are no longer recognized by the Zotero and Citavi plugin in the item listings Only in the single item view Zotero picks up the COinS. Citavi doesn't. I do not have time to dig further into this, but might be relate to a bug fixed in 1.7.0 [DS-748] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-829) OAI Extended Addon : Adding filter and modifying capacities to the OAI interface
[
https://jira.duraspace.org/browse/DS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20368#action_20368
]
Robin Taylor commented on DS-829:
-
Another wee comment. The existing code in Harvest.harvest(..) takes the stance
that withdrawn items should always be included in the result set flagged as
withdrawn even if they had restricted visibility. I guess the logic is that
they may in the past have been harvested therefore we need to tell harvesters
that they have now been withdrawn. this means that all the OAI-extended filters
would need to check that the item was not flagged as withdrawn before filtering
it. Another argument for doing the filtering in Harvest. The pseudo logic would
be amended to be...
Read database
If not withdrawn
{
then apply filters
If not required then go back and read another item
}
add to result set
OAI Extended Addon : Adding filter and modifying capacities to the OAI
interface
Key: DS-829
URL: https://jira.duraspace.org/browse/DS-829
Project: DSpace
Issue Type: New Feature
Components: OAI-PMH
Reporter: João Melo
Assignee: Robin Taylor
Fix For: 1.8.0
Attachments: OAIExtended-v2.2.tar.gz,
OAIExtended_v2.1_with_documentation.tar.gz
Purpose
The OAI Extended Addon was initially developed to allow DSpace to be
compliant with the Driver project guidelines
(http://www.driver-repository.eu).
How it works?
When an OAI-PMH request is received, the DSpace database is queried through
the standard OAI Interface included in DSpace. After that, the OAI Extended
Addon starts to work. First, the list of items retrieved from the database is
filtered by a Filter Mechanism, after that, each item associated metadata is
modified by a Modifier Mechanism. The results of both actions are returned to
the harvester that performed the request.
Because of the initial purpose, most of the filters and modifiers implemented
are specific to the Driver compliance issue. But there is an easy way to
develop your own filters and/or modifiers, just by extending the abstract
class Filter and/or Modifier. More information is included in the attachment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Closed: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Donohue closed DS-906. -- Resolution: Duplicate For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20371#action_20371 ] Mark Diggory commented on DS-906: - I was rejecting it. Just making recommendation for future reference. There will be many reasons to need special behavior on the policies applied to the item and bitsream. Consider that embargo will be broken if you just overwrite with default policies. In this regard rhis may not be duplicate, but clarify that more thought needs to go into the behavior. Note: all that needs to happen to have abusiness tier is to agree it exist and flag code/classes as belonging to it. For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20372#action_20372 ] Tim Donohue commented on DS-906: Mark, I'd disagree slightly around your final note. It's not enough to just agree that a business tier exists. We need a place for it to exist (e.g. 'dspace-business' module?), and we also need a few best practices or at least recommendations/examples in place -- otherwise we'll have some people starting to use Services, and others starting to build various Utility classes, and others going down yet another implementation path. You asked several good questions in your previous comment which point to the fact that there may be some recommendations we'd want to be making. At the very least, it'd be good to create a place for business logic work to occur, and find a few people who want to start building some examples. That way, we can point to those examples as best practices or recommendations in the future, and little-by-little move more business logic out of the various UIs and into the new 'business tier'. In any case, we probably should move this discussion elsewhere (wiki or dspace-devel) as it probably is not the best future reference sitting in a closed JIRA issue. We also should finalize amongst the Committers whether we all are in agreement around a common 'business tier', and where we'd like that code to be placed. This could be good to touch upon and agree upon at OR11, if not sooner. For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20373#action_20373 ] Mark Diggory commented on DS-906: - Moving that discussion is fine with me... My comment may have masked the important final point however, which still seems salient. Does the behavior of exposing this checkbox and blowing away the existing permissions break embargoed items? We can follow up in the original ticket if using this one seems to be a problem. For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20375#action_20375 ] Tim Donohue commented on DS-906: According the DS-525, the issue of embargoed items is documented as a warning in our Documentation: https://wiki.duraspace.org/display/DSDOC/System+Administration#SystemAdministration-Movingitems If anyone disagrees with how embargoed items were/are handled by DS-525, I'd suggest opening up a new issue relating to that (which we can add a new patch to as necessary). In my opinion, this current issue (DS-906) seems unrelated to that question, as it doesn't even mention embargoed items in the title or description (rather its title/description is almost an exact duplicate of DS-525). For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20378#action_20378 ] Mark Diggory commented on DS-906: - I actually already reopened https://jira.duraspace.org/browse/DS-171 to address improving the embargo system because I disagreed with the decisions made on it. For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20380#action_20380 ] Tim Donohue commented on DS-906: Mark, I'd highly recommend *against* reopening any issue which has already seen a formal release in DSpace. Doing so can play havoc with our current (auto-generated) History page at: https://wiki.duraspace.org/display/DSDOC/HistoryEssentially, that History page tracks which *version* each patch/fix was released in. So, for example, if you were to reopen DS-525 (which is listed as being released in 1.7.0), change it, and then change its fixed version to 1.8.0, suddenly it'd no longer be tracked as being originally released in 1.7.0. Even if you listed it as *both* released in 1.7.0 and 1.8.0, we'd no longer have any human-readable information regarding *exactly what new changes* went into 1.8.0. Essentially, it's a can of worms, and the best way to avoid it is to instead open up a *new bug report* and link it to the older, closed issue. That way, new issues/fixes can be tracked released *separate* from older, already released code. Hopefully this makes sense -- essentially, we should *only* reopen issues if they are both not fixed properly AND unreleased. As soon as they become released, they appear in our History page. So, to avoid oddities/inaccurate tracking in our History page, after that point, we should recommend opening a new issue to describe new concerns/problems and linking it back to the older, closed issue. As for DS-171, I'm actually not sure why you reopened that issue? It was previously marked as closed won't fix because it specifically described a hack/customization which could be used to implement Embargo in pre-1.6.0 DSpace JSPUI (that hack/customization is described here: https://wiki.duraspace.org/display/DSPACE/Embargo+on+Bitstream+%28JSP%29). As soon as 1.6.0 came out, it released an entirely different Embargo framework, which essentially made the implementation described in DS-171 obsolete. So, I'm not sure you actually should have reopened DS-171, as it describes an obsolete implementation of Embargo. Rather, if there are existing embargo concerns/issues, they likely should instead be logged as new issues. OK -- I realize we've now gone off the deep end in terms of these comments. None of these recent comments (mine included) have much to do with DS-906 itself -- so, we both may want to move this ongoing discussion to dspace-devel :) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-906) For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection
[ https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20381#action_20381 ] Tim Donohue commented on DS-906: One last brief note: The officially released 1.6.0 Embargo feature was described in : DS-317 As noted above, DS-171 is unrelated to that feature, and is now obsolete for anyone using DSpace 1.6 or above. For moving items in the Admin UI, add checkbox option to replace resource policies with defaults of the new collection -- Key: DS-906 URL: https://jira.duraspace.org/browse/DS-906 Project: DSpace Issue Type: Improvement Components: XMLUI Affects Versions: 1.7.2, 1.8.0 Reporter: Bill Hays This is a single call in the API: item.inheritCollectionDefaultPolicies(targetCollection) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Issue Comment Edited: (DS-171) Embargo_on_Bitstream_(JSP)
[ https://jira.duraspace.org/browse/DS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20382#action_20382 ] Tim Donohue edited comment on DS-171 at 5/18/11 5:46 PM: - Re-Closing this issue. Please open up a new issue to describe any new changes to the DSpace Embargo feature (DS-317) which was released in 1.6.0. This current issue (DS-171) should be considered obsolete, as it describes an unsupported implementation of Embargo that worked in pre-1.6.0 DSpace (specifically 1.3.2, according to the wiki docs). The full description of this unsupported implementation of Embargo is described on the wiki docs linked from the description above: https://wiki.duraspace.org/display/DSPACE/Embargo+on+Bitstream+%28JSP%29 was (Author: tdonohue): Re-Closing this issue. Please open up a new issue to describe any new changes to the DSpace Embargo feature (DS-371) which was released in 1.6.0. This current issue (DS-171) should be considered obsolete, as it describes an unsupported implementation of Embargo that worked in pre-1.6.0 DSpace (specifically 1.3.2, according to the wiki docs). The full description of this unsupported implementation of Embargo is described on the wiki docs linked from the description above: https://wiki.duraspace.org/display/DSPACE/Embargo+on+Bitstream+%28JSP%29 Embargo_on_Bitstream_(JSP) -- Key: DS-171 URL: https://jira.duraspace.org/browse/DS-171 Project: DSpace Issue Type: Improvement Components: Documentation, DSpace API, JSPUI, OAI-PMH, REST API (experimental), SWORD, Unit Testing Framework, XMLUI Reporter: Charles Kiplagat Priority: Major Bitstreams all have a resource policy. Most of the time this is a anonymous read policy. If a bitstream has no anonymous read policy then it cannot be read, so effectively it is under embargo.Now if you could set an end date for that embargo, it would be so much nicer. But this is already possible: DSpace allows resource policies to have a start date and an end date: so if you set an anonymous read policy with a start date of januari 1 2009, it is effectively under embargo until januari 1 2009. Now all this change does, is: * allow a submitter to set an embargo date when uploading a new file (optional) * allow an administrator to set the start and end dates of a resource policy for bitstreams * display the embargo date in a nice way when displaying an item with bitstream information, and disabling the link to that bitstream if it is under embargo (an administrator can always link to the bitstream) https://openaccess.leidenuniv.nl/handle/1887/12291 http://wiki.dspace.org/index.php/Embargo_on_Bitstream_(JSP) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-875) DSpace Configuration service error when using dspace script.
[
https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20383#action_20383
]
Kevin Van de Velde commented on DS-875:
---
Stuart,
Although I'm also not a fan of losing the CLASSPATH the issue is should a
CLASSPATH be set and this CLASSPATH doesn't have any subdirectories (don't know
if this can happen) it will not retrieve a single config file from any of the
jars in the FULLPATH.
Once the PathMatchingResourcePatternResolver encounters an invalid (invalid
being a directory without a subdirectory) CLASSPATH option it will crash.
Perhaps we need to look into something that loops over all classpath options
and attempts to resolve them one by one, but I'm not a fan this personally
because I find that quite dirty.
Personally I would prefer another option but I can't seem to think of one at
the moment.
DSpace Configuration service error when using dspace script.
--
Key: DS-875
URL: https://jira.duraspace.org/browse/DS-875
Project: DSpace
Issue Type: Bug
Components: DSpace API
Affects Versions: 1.7.1
Reporter: Kevin Van de Velde
Priority: Major
Fix For: 1.7.2
Attachments: dspace_script_bugfix.patch
When using the dspace script (located in {dspace.dir}/bin directory) in
DSpace 1.7.1 the following error will occur:
java.lang.IllegalArgumentException: Resource path
[{dspace.dir.path}/bin/dspace] does not denote a directory
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.retrieveMatchingFiles(PathMatchingResourcePatternResolver.java:563)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindMatchingFileSystemResources(PathMatchingResourcePatternResolver.java:543)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingFileResources(PathMatchingResourcePatternResolver.java:526)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:342)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:276)
at
org.dspace.servicemanager.config.DSpaceConfigurationService.loadInitialConfig(DSpaceConfigurationService.java:390)
at
org.dspace.servicemanager.config.DSpaceConfigurationService.init(DSpaceConfigurationService.java:62)
at
org.dspace.servicemanager.DSpaceKernelImpl.start(DSpaceKernelImpl.java:145)
at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:51)
This error in itself is completely harmless since it is actually a log bug,
there is an e.printstacktrace() that should have been a log.error, the
configuration service will just fail to load the dspace config files in the
jars (which is harmless since the configuration service isn't used by DSpace
at the moment).
The reason why the error is thrown lies in the configuration service, the
following method is called when attempting to retrieve .cfg files from the
classpath.
PathMatchingResourcePatternResolver patchMatcher = new
PathMatchingResourcePatternResolver();
Resource[] resources =
patchMatcher.getResources(classpath*:dspace/config-*.cfg);
From the Spring documentation
(http://static.springsource.org/spring/docs/2.5.x/reference/resources.html):
Please note that classpath*: when combined with Ant-style patterns
will only work reliably with at least one root directory before the
pattern starts, unless the actual target files reside in the file
system. This means that a pattern like classpath*:*.xml will not
retrieve files from the root of jar files but rather only from the
root of expanded directories. This originates from a limitation in the
JDK's ClassLoader.getResources() method which only returns file system
locations for a passed-in empty string (indicating potential roots to
search).
From the dspace script:
FULLPATH=$CLASSPATH:$JARS:$DSPACEDIR/config
java $JAVA_OPTS -classpath $FULLPATH org.dspace.app.launcher.ScriptLauncher
$@
Conclusion:
The problem is caused by the fact that the JDK is expecting directories or
directories with at least one subdirectory to be passed in the FULLPATH
argument when invoking Java. It is obvious that {dspace.dir}/bin/dspace
violates these requirements, causing the process to throw an exception when
trying to use this location as a directory. In order to solve this, I suggest
removing the $CLASSPATH variable from the FULLPATH argument because I do not
expect it to be of any use when running DSpace processes. I have verified the
behavior of the dspace command after removing the $CLASSPATH variable and all
processes seem to be working
[Dspace-devel] [DuraSpace JIRA] Created: (DS-908) Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace
Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace -- Key: DS-908 URL: https://jira.duraspace.org/browse/DS-908 Project: DSpace Issue Type: Improvement Components: Discovery, Documentation, DSpace API, JSPUI, LNI, OAI-PMH, REST API (experimental), Service Manager, Solr, SWORD, Unit Testing Framework, XMLUI Affects Versions: 1.7.1, 1.7.0, 1.6.2 Reporter: Mark Diggory Priority: Major Fix For: 1.8.0 I would like to readdress how the current embargo is implemented in DSpace, this Issue comes up because we have started working on an Embargo solution that actually uses the start/end dates of resource policies to enforce the embargo rather than a cron tab script. This approach is currently under deployment/test in IDEALS and based on existing embargo work that was completed there by The new proposed approach would allow for Embargo to be applied at either the Item level or individual Bitstream levels as a series of ResourcePolicies that use start/stop datestamps currently on the ResourcePolicy object and does not require executing a cronjob to adjust the state of the Item Thus the record and enforcement of embargo is stateless. Being stateless means that the policies do not change over time, just the resulting decision of the evaluation that enforces of those policies changes. The AuthorizationManager already supports the enforcement of timeframes in ResourcePolicies. I would like to propose that we expand ResourcePolicy in the following manner: 1.) To be a better DSpace Domain Model citizen and that would include having name and description fields available to define the reason for a resource policy being set. 2.) Establishment of a RESTRICT Action that would be enforced by the AuthorizationManager to allow for Explicit Definition of the Embargo Policy on Annonymous Users. For example: Bitstream A -- ResurcePolicy( Action=RESTRICT, Group=Annonymous, start=20110101, end=20120101, name=Embargo, description=Embargoed as required by publisher.) Bitstream A -- ResurcePolicy( Action=READ, Group=UniversityAffiliates, start=null, end=null, name=Local University Affiliates, description=Local University Affiliates are Exempt from Embargo Restriction.) The previous example would enforce Embargo and Access rights Explicitly and Clearly in the Policies attached to the Bitstream and/or Item. The AuthorizationManager may need minor enhancement to address inheritance of ResourcePolicies assigned on parent Items. It may be advisable to use such inheritance to enforce DEFAULT_XXX policies rather than copying them into place on each and every Bitstream/Bundle and Item created, this will reduce the bloat of ResourcePolicies currently in effect in the existing system. And important benefit of these changes to ResourcePolicies and the underlying AuthorizationManager framework are that they can then be used to encode the explicit technical or administrative metadata sections into the AIP or METS manifests concerning the Policies that are in effect on the Item and its contents. Adjustments to the DSpace SIP Profile to capture enforcement of embargo details by consumers of those tools would be more clearly expressed and machine automatable than dumping it intot he metadata. Achieving Machine actionability means that Ingest Packagers and services that rely on them can define a more concrete business logic to be maintained. As we evolve the Metadata capabilities to support system/tech/admin/descriptive metadata sections for all parts of the item, we can consider that the ResourcePolices will inform the production of metadata about the embargo state of the Item being exposed in OAI / SWORD /METS packagers and so-on. But for now, we really need to set a standard that actual Resource Policies be the mechanism that enforces the access rules/policies within the system and not some metadata field set in the item metadata description. Somewhat a concern is how other areas of DSpace treat ResourcePolicies rather bluntly. Recommend that ResourcePolicies should be managed in central manner (such as ResourcePolicyService: or ResorcePolicyManager) such that the manner in which policies are enforced or allowed to be edited does NOT cause emergent conflicting behavior across different parts of the system such as those described within DS-906 and DS-525. According the DS-525, the issue of embargoed items is documented as a warning in our Documentation: https://wiki.duraspace.org/display/DSDOC/System+Administration#SystemAdministration-Movingitems I consider this documentation insufficient as a solution to the problem of embargo permissions getting overridden in the mapping. A more appropriate solution would show to the user the
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-803) 'dspace harvest -g' (ping) doesn't
[ https://jira.duraspace.org/browse/DS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20388#action_20388 ] Graham Triggs commented on DS-803: -- The harvester CLI calls various methods on the harvester object (OAIHarvester) for each 'command'. But the 'ping' command only checks the parameters and does nothings else. There is a method on the Harvest object that tests the server, looks like it just needs to call that if the parameters are valid: harvester.verifyOAIharvester(oaiSource, oaiSetID, metadataKey, /* true / false for testing ORE */); 'dspace harvest -g' (ping) doesn't -- Key: DS-803 URL: https://jira.duraspace.org/browse/DS-803 Project: DSpace Issue Type: Bug Components: DSpace API Affects Versions: 1.6.2 Reporter: Mark H. Wood Priority: Major The 'ping' code carefully checks its arguments and then exits without doing anything. http://sourceforge.net/mailarchive/forum.php?thread_name=004201cbb7e3%24bd5d5220%243817f660%24%40caforum_name=dspace-tech -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
