[Dspace-devel] [DSJ] Created: (DS-580) DIDL format include HTML element if the item has no files
DIDL format include HTML element if the item has no files - Key: DS-580 URL: http://jira.dspace.org/jira/browse/DS-580 Project: DSpace 1.x Issue Type: Bug Components: OAI-PMH Affects Versions: 1.6.0, 1.5.2, 1.5.1, 1.5.0 Reporter: Andrea Bollini Assignee: Andrea Bollini Priority: Minor Fix For: 1.6.1, 1.7 didl:DIDL xsi:schemaLocation=urn:mpeg:mpeg21:2002:02-DIDL-NS http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/did/didl.xsd didl:DIDLInfo dcterms:created xsi:schemaLocation=http://purl.org/dc/terms/ 2010-05-13T07:42:22Z/dcterms:created /didl:DIDLInfo didl:Item id=uuid-bfe746d8-de20-4b48-a385-807584e99cd8 didl:Descriptor didl:Statement mimeType=application/xml; charset=utf-8 dii:Identifier xsi:schemaLocation=urn:mpeg:mpeg21:2002:01-DII-NS http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/dii/dii.xsd;urn:hdl:10281/1584/dii:Identifier /didl:Statement /didl:Descriptor didl:Descriptor didl:Statement mimeType=application/xml; charset=utf-8 oai_dc:dc xsi:schemaLocation=http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd; dc:contributor.../dc:contributor dc:date2008-07-21T07:17:13Z/dc:date /oai_dc:dc /didl:Statement /didl:Descriptor PThere are no files associated with this item./P /didl:Item /didl:DIDL -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Jira workflow etc
Following on from the developer-meeting discussion about Jira workflow and best practices here are a few thoughts:- The default workflow can be seen here - http://www.atlassian.com/software/jira/docs/v3.13/default_workflow.html. It does appear to be possible to customise the default workflow to add steps - http://www.atlassian.com/software/jira/docs/v3.13/workflow.html. Indeed with the Enterprise Edition you can customise it by issue type if you really wanted to. We could add in another step of Received at the beginning of the workflow giving us... Received - Open - In_Progress - Resolved - Closed - Re_Opened Obviously the flow for any particular issue does not have to go through all steps. My understanding of these steps would be... Received- A new issue that has yet to be reviewed. Open- Reviewed and not immediately closed. As things stand the issue may or may not be assigned to someone. In_Progress - Bit of an anomaly here. More useful to a manager monitoring someones work. Resolved- The person to whom the issue was assigned considers the item to be resolved eg patch created and committed. Closed - The person who reported the issue is satisfied that the issue is resolved. Re_Opened - Shouldn't have been closed. I am not sure about this but I think it could be possible to change the status of an issue to be In_Progress when it is assigned. That would allow us to distinguish between those that are Open but not yet assigned, and those that have been assigned. On the other hand we could just ignore that step or get rid of it. There also appears to be a divide currently amongst those that choose to resolve issues and those that close them. What I have listed above is just my interpretation of the workflow but I do think that all issues should ultimately be closed. Having said that, I am not sure its practical to expect the reporter to close an issue (do they even have permission to do so ?), it might need to be the resolver (or reviewer ?). On a different subject - Affects Version and Fix Version. My understanding is that 'Affects' is the version(s) in which the bug was discovered, 'Fix' is the version(s) in which it will be fixed. I have a feeling I once read this in the Jira docs but I could be making that up. Please comment. Once we settle on something I'll pester Tim to help me make any necessary changes and document them. Cheers, Robin. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Jira workflow etc
== Received vs Open ==
(partial rehash of what said in #duraspace 2010-05-12)
Due to the difficulty in successfully keeping up with new tickets created,
especially during the tail of weekly committer meetings, I like the idea of
having received. It will help to distinguish what has been submitted, and
it just rotting, vs something that has atleast been considered. If JIRA
could spit out a weekly email of all things {received}, as well as all
things that moved from {received to open} in the past week, and sent that to
dspace-tech, I think that would be helpful to engage the community a little
more. I.e. a ticket about doing something in jetty will get a better
response from the mailing list, than from jira.
Thus, someone can patrol the {received} tickets each week, to make sure they
either become {open} or {closed - won't fix}. Then in committer meetings we
can discuss issues that need more discussion, such as does this patch make
sense.
Also, with regard to new tickets that are feature requests / improvements. I
think these might be especially good to get community feedback for. Such as
ideas from dsalo like: DS-293 [Update input-forms from the UI, no restart
required].
I like how things like Google Moderator works, and I would recommend adding
{recieved::feature-request} to moderator. Thus far, I've been adding things
somewhat to http://www.google.com/moderator/#15/e=3fb5t=3fb5.40
This would work somewhat similar to how in times past, a survey went out,
and then a wordle tag helps you to see in big letters what is wanted. But
this could be equally, or more effective.
== Resolved vs Closed ==
I was wondering about the difference between resolved and closed.
When I do my commits that fix the problem (even if I was the reporter), I
choose to resolve the ticket.
To close it, I think should be the responsibility of the tester, the
reviewer, or even the release coordinator. They look over all committed
fixes, and once its been properly tested and solves the problem
satisfactorily, then they get to close it.
Peter Dietz
Systems Developer/Engineer
Ohio State University Libraries
On Thu, May 13, 2010 at 12:52 PM, Graham Triggs grahamtri...@gmail.comwrote:
On 13 May 2010 16:21, TAYLOR Robin robin.tay...@ed.ac.uk wrote:
Indeed with the Enterprise Edition you can customise it by issue type if
you really wanted to. We could add in another step of Received at the
beginning of the workflow giving us...
Received - Open - In_Progress - Resolved - Closed - Re_Opened
Seems reasonable.
My understanding of these steps would be...
Received- A new issue that has yet to be reviewed.
Open- Reviewed and not immediately closed. As things
stand the issue may or may not be assigned to someone.
In_Progress - Bit of an anomaly here. More useful to a manager
monitoring someones work.
Resolved- The person to whom the issue was assigned
considers the item to be resolved eg patch created and committed.
Closed - The person who reported the issue is satisfied that the
issue is resolved.
Re_Opened - Shouldn't have been closed.
That is the long and short of it, yes.
I am not sure about this but I think it could be possible to change the
status of an issue to be In_Progress when it is assigned. That would allow
us to distinguish between those that are Open but not yet assigned, and
those that have been assigned. On the other hand we could just ignore that
step or get rid of it.
I don't see the point in this. If you want to distinguish an unassigned
item, you can just leave it (or set it) to be unassigned. As you say before,
In Progress does mean something - that somebody has stated that they are
actively working on it. That does not have to equate to monitoring someone -
in our context, it's a useful means to communicate to each other that we are
actively working on a specific issue, rather than being an issue that has
been assigned that we just haven't got around to doing anything about yet
(which someone could easily offer to take up).
Unfortunately, we're still on Jira 3, when we do upgrade we will have some
nice drag and drop tools for dealing with issues (/cards), and at that
point, effective use of the In Progress status will show it's worth.
There also appears to be a divide currently amongst those that choose to
resolve issues and those that close them. What I have listed above is just
my interpretation of the workflow but I do think that all issues should
ultimately be closed. Having said that, I am not sure its practical to
expect the reporter to close an issue (do they even have permission to do so
?), it might need to be the resolver (or reviewer ?).
I'm actually not a fan of the Closed status. Having worked with Jira in a
number of cases where I've needed to re-organise issues after they've been
worked on - either to add some additional categorisation, re-organisation of
[Dspace-devel] [DSJ] Commented: (DS-575) On item pages, collection link should go to title browse, not collection splash page
[
http://jira.dspace.org/jira/browse/DS-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=11419#action_11419
]
Peter Dietz commented on DS-575:
I agree that its bad that user has no idea what they're supposed to do, when
they reach a naked collection page. But then for collections that have a nice
collection description and logo, the collection might want the user to see the
collection page. To me it seems like a potential solution would be to have
{browse-by-title} displayed on the collection page.
Part of the ideal (not too far off) solution would be to have the link go to
collection home page, but then to build in the stuff of that collection into
the collection page. So imagine this discovery work embedded into that
collection page.
http://www.datadryad.org/repo/search?query=rpp=10group_by=nonesort_by=scoreorder=DESCsubmit=Go
and perhaps allowing the collection you are in to be a facet that can be
closed to expand your scope of items.
I.e. current collection equals science journal 2006, they might be interested
in stuff in neighboring collections, or contained within the community, or
expand scope completely and be able to find things in entire repo.
On item pages, collection link should go to title browse, not collection
splash page
Key: DS-575
URL: http://jira.dspace.org/jira/browse/DS-575
Project: DSpace 1.x
Issue Type: Improvement
Affects Versions: 1.5.2
Reporter: Dorothea Salo
On item summary pages, DSpace currently places a link back to the item's
owning collection's splash page. This can be confusing to users expecting to
click through to all the items in the collection, especially when there is no
collection-description text in the owning collection (quite a common
circumstance in our instance). Users tend to think that the recently
submitted list contains every item in the collection.
Linking to the collection's title-browse page instead un-confuses these
users, and ensures that all users will get to something relatively useful.
Users wishing to go directly to the collection splash page can still do so
via the breadcrumb trail at page-top.
--
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
--
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Commented: (DS-533) Collection Short Description not visible
[ http://jira.dspace.org/jira/browse/DS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=11420#action_11420 ] Peter Dietz commented on DS-533: The short description is exposed via the DRI http://demo.dspace.org/xmlui//metadata/handle/123456789/2/mets.xml as dc.description.abstract so it appears as though its the theme which is not showing the short description. Collection Short Description not visible Key: DS-533 URL: http://jira.dspace.org/jira/browse/DS-533 Project: DSpace 1.x Issue Type: Bug Affects Versions: 1.5.2, 1.6.0 Reporter: Ronee Francis It looks like the Collection Short Description (in Edit Collection) does not show up on collection homepage. For an example see the demo website http://demo.dspace.org/xmlui/handle/123456789/2 Ronee -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Created: (DS-581) DIDL doesn't respect the hidden fields and the oai_dc metadata section is different than the simple oai_dc implementation
DIDL doesn't respect the hidden fields and the oai_dc metadata section is different than the simple oai_dc implementation - Key: DS-581 URL: http://jira.dspace.org/jira/browse/DS-581 Project: DSpace 1.x Issue Type: Bug Components: OAI-PMH Affects Versions: 1.6.0, 1.5.2, 1.5.1, 1.5.0 Reporter: Andrea Bollini Assignee: Andrea Bollini Fix For: 1.6.1, 1.7 The MetadataExposure settings are not used and the metadata section are generated with code copied from an old version of the OAIDCCrosswalk -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Updated: (DS-574) DSpaceMETSIngester creates empty original bundle
[ http://jira.dspace.org/jira/browse/DS-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Bollini updated DS-574: -- Attachment: AbstractMETSIngester.patch DSpaceMETSIngester creates empty original bundle Key: DS-574 URL: http://jira.dspace.org/jira/browse/DS-574 Project: DSpace 1.x Issue Type: Bug Components: DSpace API Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Andrea Bollini Assignee: Andrea Bollini Priority: Minor Attachments: AbstractMETSIngester.patch If you ingest a mets package with only metadata the system will create an unnecessary empty original bundle -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Updated: (DS-573) NPE resuming submission for item with an empty bundle original
[ http://jira.dspace.org/jira/browse/DS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Bollini updated DS-573: -- Attachment: ds573.patch NPE resuming submission for item with an empty bundle original -- Key: DS-573 URL: http://jira.dspace.org/jira/browse/DS-573 Project: DSpace 1.x Issue Type: Bug Components: JSPUI Affects Versions: 1.5.0, 1.5.1, 1.5.2 Reporter: Andrea Bollini Assignee: Andrea Bollini Attachments: ds573.patch The JSPUI assumes that an existent Bundle named original mean that there are uploaded files from the user. With this assumption it show the upload-file-list jsp instead of the file-choose-upload ant thrown a NPE. The same problem happen on the verify step. Also the flash page of an item with an empty orignal bundle is wrong: there is an empty table instead of the message no files available. To reproduce the bug you need to create the item using the API or to do an ingest using the DSpaceMETSIngester (the SWORD default implementation use it). Send the submission trought the workflow system and reject the item. Resuming the submission will thrown the NPE -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Commented: (DS-524) Eperson netID is lost editing the record from the webUI
[ http://jira.dspace.org/jira/browse/DS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=11424#action_11424 ] Andrea Bollini commented on DS-524: --- using ldap.enable is not a valid workaround because with this option turned on the JSPUI changes also other behaviours (see the registration servlet) The netid field is a more sensible field than the email because it could be used (we done this) to maintain association with an external system and should never be changed... or at least it should be changed only by users that really know what they are doing. We use the netid field with a custom authentication based on CAS and also with Shibboleth where the authoritative information is an unique national ID that never changes also if user changes his mail Eperson netID is lost editing the record from the webUI --- Key: DS-524 URL: http://jira.dspace.org/jira/browse/DS-524 Project: DSpace 1.x Issue Type: Bug Components: JSPUI Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Andrea Bollini Fix For: 1.7 Attachments: ds-524-jspui.patch, eperson-edit.jsp.patch Editing an eperson record from the WebUI we lost the netid value. The only way to prevent this is set to true the property: ldap.enable The property is related to LDAP so I'm not sure if there is other implications to use it... anyway, we need to separate these two concerns. I propose to: 1) add a new configuration property to decide if the webUI is allowed to change the netid value; the authorization logic should be checked in the Servlet and not only on the client side as now is 2) always show the netid field, when appropriate as a readonly box We need to check also the XMLUI to get a common behaviour. -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Closed: (DS-453) Update paths in [dspace-source]\dspace\config\dspace.cfg
[ http://jira.dspace.org/jira/browse/DS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz closed DS-453. -- Documentation Status: Not Required (was: In Description) Resolution: Fixed It looks like the response given was satisfactory, and this is quite an old ticket with no activity, so I'll close it. Update paths in [dspace-source]\dspace\config\dspace.cfg Key: DS-453 URL: http://jira.dspace.org/jira/browse/DS-453 Project: DSpace 1.x Issue Type: Bug Components: DSpace API Affects Versions: 1.5.2 Environment: windows xp Reporter: bindu madhavi i update the following some paths in dspace.config i.e. dspace.dir assetstore.dir log.dir upload.temp.dir report.dir handle.dir but three of paths i cant see in dspace.config.i.e config.template.log4j.properties config.template.log4j-handle-plugin.properties config.template.oaicat.properties how can i update these 3 paths. -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Resolved: (DS-581) DIDL doesn't respect the hidden fields and the oai_dc metadata section is different than the simple oai_dc implementation
[ http://jira.dspace.org/jira/browse/DS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Bollini resolved DS-581. --- Documentation Status: In Comments (was: Not Required) Resolution: Fixed committed to the trunk as well DIDL doesn't respect the hidden fields and the oai_dc metadata section is different than the simple oai_dc implementation - Key: DS-581 URL: http://jira.dspace.org/jira/browse/DS-581 Project: DSpace 1.x Issue Type: Bug Components: OAI-PMH Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Andrea Bollini Assignee: Andrea Bollini Fix For: 1.6.1, 1.7 Attachments: didl-cleanup.patch, didl.patch The MetadataExposure settings are not used and the metadata section are generated with code copied from an old version of the OAIDCCrosswalk -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Resolved: (DS-580) DIDL format include HTML element if the item has no files
[ http://jira.dspace.org/jira/browse/DS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Bollini resolved DS-580. --- Resolution: Fixed committed see DS-581 DIDL format include HTML element if the item has no files - Key: DS-580 URL: http://jira.dspace.org/jira/browse/DS-580 Project: DSpace 1.x Issue Type: Bug Components: OAI-PMH Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Andrea Bollini Assignee: Andrea Bollini Priority: Minor Fix For: 1.6.1, 1.7 didl:DIDL xsi:schemaLocation=urn:mpeg:mpeg21:2002:02-DIDL-NS http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/did/didl.xsd didl:DIDLInfo dcterms:created xsi:schemaLocation=http://purl.org/dc/terms/ 2010-05-13T07:42:22Z/dcterms:created /didl:DIDLInfo didl:Item id=uuid-bfe746d8-de20-4b48-a385-807584e99cd8 didl:Descriptor didl:Statement mimeType=application/xml; charset=utf-8 dii:Identifier xsi:schemaLocation=urn:mpeg:mpeg21:2002:01-DII-NS http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/dii/dii.xsd;urn:hdl:10281/1584/dii:Identifier /didl:Statement /didl:Descriptor didl:Descriptor didl:Statement mimeType=application/xml; charset=utf-8 oai_dc:dc xsi:schemaLocation=http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd; dc:contributor.../dc:contributor dc:date2008-07-21T07:17:13Z/dc:date /oai_dc:dc /didl:Statement /didl:Descriptor PThere are no files associated with this item./P /didl:Item /didl:DIDL -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Updated: (DS-573) NPE resuming submission for item with an empty bundle original
[ http://jira.dspace.org/jira/browse/DS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Bollini updated DS-573: -- Affects Version/s: 1.6.0 NPE resuming submission for item with an empty bundle original -- Key: DS-573 URL: http://jira.dspace.org/jira/browse/DS-573 Project: DSpace 1.x Issue Type: Bug Components: JSPUI Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Andrea Bollini Assignee: Andrea Bollini Fix For: 1.6.1, 1.7 Attachments: ds573.patch The JSPUI assumes that an existent Bundle named original mean that there are uploaded files from the user. With this assumption it show the upload-file-list jsp instead of the file-choose-upload ant thrown a NPE. The same problem happen on the verify step. Also the flash page of an item with an empty orignal bundle is wrong: there is an empty table instead of the message no files available. To reproduce the bug you need to create the item using the API or to do an ingest using the DSpaceMETSIngester (the SWORD default implementation use it). Send the submission trought the workflow system and reject the item. Resuming the submission will thrown the NPE -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Resolved: (DS-573) NPE resuming submission for item with an empty bundle original
[ http://jira.dspace.org/jira/browse/DS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Bollini resolved DS-573. --- Resolution: Fixed Fix Version/s: 1.7 1.6.1 committed to both trunk and 1.6.x branch NPE resuming submission for item with an empty bundle original -- Key: DS-573 URL: http://jira.dspace.org/jira/browse/DS-573 Project: DSpace 1.x Issue Type: Bug Components: JSPUI Affects Versions: 1.5.0, 1.5.1, 1.5.2 Reporter: Andrea Bollini Assignee: Andrea Bollini Fix For: 1.6.1, 1.7 Attachments: ds573.patch The JSPUI assumes that an existent Bundle named original mean that there are uploaded files from the user. With this assumption it show the upload-file-list jsp instead of the file-choose-upload ant thrown a NPE. The same problem happen on the verify step. Also the flash page of an item with an empty orignal bundle is wrong: there is an empty table instead of the message no files available. To reproduce the bug you need to create the item using the API or to do an ingest using the DSpaceMETSIngester (the SWORD default implementation use it). Send the submission trought the workflow system and reject the item. Resuming the submission will thrown the NPE -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Commented: (DS-568) Time Stamps for metadatavalues (date accessioned/available) differ from last modified time stamp in item table
[ http://jira.dspace.org/jira/browse/DS-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=11432#action_11432 ] Kim Shepherd commented on DS-568: - I suspect (especially given your location..) that this is a GMT vs. Local Time issue, and could be by design... Can anyone else comment? Time Stamps for metadatavalues (date accessioned/available) differ from last modified time stamp in item table -- Key: DS-568 URL: http://jira.dspace.org/jira/browse/DS-568 Project: DSpace 1.x Issue Type: Bug Components: DSpace API Affects Versions: 1.5.1, 1.6.0 Reporter: Claudia Jürgen Another date issue: During submission (both via UI and as import) time stamps are created differently: item table last_modified got real time whereas metadatavalues like dc.date.accessioned and dc.date.available got real time -2 hours -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Assigned: (DSRV-7) Adjust Service Activators to be able to start from Spring configuration
[ http://jira.dspace.org/jira/browse/DSRV-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Diggory reassigned DSRV-7: --- Assignee: Mark Diggory Adjust Service Activators to be able to start from Spring configuration --- Key: DSRV-7 URL: http://jira.dspace.org/jira/browse/DSRV-7 Project: DSpace Services Module Issue Type: Sub-task Affects Versions: 2.0.1 Reporter: Mark Diggory Assignee: Mark Diggory Fix For: 2.0.1 Adjusting the Activators to be activated by querying the DSpaceServiceManager allows them to be added elsewhere than the properties files. -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Created: (DSRV-7) Adjust Service Activators to be able to start from Spring configuration
Adjust Service Activators to be able to start from Spring configuration --- Key: DSRV-7 URL: http://jira.dspace.org/jira/browse/DSRV-7 Project: DSpace Services Module Issue Type: Sub-task Affects Versions: 2.0.1 Reporter: Mark Diggory Fix For: 2.0.1 Adjusting the Activators to be activated by querying the DSpaceServiceManager allows them to be added elsewhere than the properties files. -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Created: (DSRV-8) Correct errors when locating legacy configuration properties and files.
Correct errors when locating legacy configuration properties and files. --- Key: DSRV-8 URL: http://jira.dspace.org/jira/browse/DSRV-8 Project: DSpace Services Module Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Mark Diggory Assignee: Mark Diggory Fix For: 2.0.1 ConfigurationService assigned wrong location for dspace-config servlet context property. Test Classes did not local local.properties due to naming convention change. Added Legacy and New naming convention to load properties from. -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DSJ] Updated: (DS-544) Removal of mapped items can lead to NPE
[ http://jira.dspace.org/jira/browse/DS-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Shepherd updated DS-544: Attachment: DS-544.patch Attached patch which makes the following changes: org.dspace.app.webui.servlet.admin.ItemMapServlet: -- * If ItemsID[] is null, add a none-removed message and skip attempt at removing mapping (this is how the Add action was handled already) * Remove some old, obselete code for add action that's been commented out for a long time, to tidy up ItemMapServlet itemmap-info.jsp: -- * Add handling for the none-removed message in itemmap-info.jsp Messages.properties: -- * Add a new i18n key: jsp.tools.itemmap-info.msg.none-removed = No items selected, none removed. Tested and committed to trunk and dspace-1.6.x branch Removal of mapped items can lead to NPE --- Key: DS-544 URL: http://jira.dspace.org/jira/browse/DS-544 Project: DSpace 1.x Issue Type: Bug Components: JSPUI Affects Versions: 1.6.0 Reporter: Claudia Jürgen Assignee: Kim Shepherd Priority: Minor Fix For: 1.6.1, 1.7 Attachments: DS-544.patch When clicking remove on the list of mapped items without having selected an item, leads to an internal error due to a NPE. This should be handled more graceful. -- 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 -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
