[
http://jira.dspace.org/jira/browse/DS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11674#action_11674
]
Jim Ottaviani edited comment on DS-587 at 9/10/10 1:29 PM:
-----------------------------------------------------------
Thanks Tim. You summed it up well for me with your two options, and I think
what you propose is exactly right. I also think I misunderstood your and
bollini's concerns, which is why I went on so long about why we proposed (and
do) what we did. I clearly misunderstood the 404 issue, about which I now agree
100%: that's the status code a withdrawn item should return. Definitely not
200...
I'm definitely not smart enough to comment on Mark's suggestion in any detail.
I don't see the problem with having it in the UI, but that's where I live every
day, and am used to seeing and tweaking things there. That said, withdrawing an
item is (or at least should be) an infrequent enough occurrence, and exposing
metadata is not likely to be collection-specific enough, to require different
policies. So if I understand his suggestion then I agree that predefining this
system-wide (here at Michigan we'd default to Anonymous, obviously) should be
fine in almost all cases.
We may be able to take a shot at modifying our patch to do these things, but
have to look at how much of Jose's time I can get in the near future. He may
contact you about this as well to learn more about what we can do.
Thanks again.
was (Author: jimottaviani):
Thanks Tim. You summed it up well -- at least for me -- with your two
options, and I think what you propose is exactly right. I also think I
misunderstood your and bollini's concerns, which is why I went on so long about
why we proposed (and do) what we did. I clearly misunderstood the 404 issue,
about which I now agree 100%: that's the status code a withdrawn item should
return. Definitely not 200...
I'm definitely not smart enough to comment on Mark's suggestion in any detail.
I don't see the problem with having it in the UI, but that's where I live every
day, and am used to seeing. That said, withdrawing an item is (or at least
should be) an infrequent enough occurrence, and exposing metadata is not likely
to be collection-specific enough to require different policies, that if I
understand his suggestion then I agree that predefining this system-wide (here
at Michigan we'd default to Anonymous, obviously) should be fine in almost all
cases.
We may be able to take a shot at modifying our patch to do these things, but
have to look at how much of Jose's time I can get in the near future. He may
contact you about this as well to learn more about what we can do.
Thanks again.
> add the capability to indicate a withdraw reason to an item ( tombstone )
> -------------------------------------------------------------------------
>
> Key: DS-587
> URL: http://jira.dspace.org/jira/browse/DS-587
> Project: DSpace 1.x
> Issue Type: New Feature
> Components: JSPUI
> Affects Versions: 1.6.0
> Environment: This is a change to the base functionality of the jspui.
> Reporter: Jose Blanco
> Priority: Minor
> Attachments: confirm-withdraw-item.jsp, embargo.jsp, tombstone.jsp
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I have already made the changes to our instance of dspace. Here is an
> explanation of what the tombstone functionality works at our instance.
> When an item is withdrawn the user is presented with these options for
> the reason of withdraw ( these reasons live in the file
> tools/confirm-withdraw-item.jsp ):
> Removed from view by legal order.
> Removed from view by the University of Michigan.
> Removed from view at request of the author.
> The user makes his selection and the item is withdrawn. When the item is
> accessed the reason for the withdraw is
> displayed in the box containing the bitstreams.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
