Opened 12 years ago

Last modified 12 years ago

#1147 reopened defect

unable to delete a file attached to a metadata

Reported by: landry Owned by: geonetwork-devel@…
Priority: major Milestone: v2.8.0
Component: General Version: v2.8.0RC0
Keywords: Cc:

Description

We heavily use files attached to metadata in our geonetwork 2.8.0rc0 instance. Attaching a file works fine, but removing it through the 'delete' button next to thefile name is impossible, the operation fails with a 'ServiceNotAllowedEx : Service not allowed' exception popup.

The workaround we've found so far is to remove the whole <gmd:CI_OnlineResource> subtree (which as a sidenote doesnt delete the file from the metadata_data directory on the server) , and reupload the file with a different name.

Interesting thing, after uploading a file, there's a resources.get call made with an empty fname, leading to a backtrace in the log. Related ?

Attaching geonetwork logs for file upload and removal try.

Attachments (2)

remove-file.log (3.2 KB ) - added by landry 12 years ago.
log of file removal button click
upload-file.log (8.4 KB ) - added by landry 12 years ago.
upload file log

Download all attachments as: .zip

Change History (6)

by landry, 12 years ago

Attachment: remove-file.log added

log of file removal button click

by landry, 12 years ago

Attachment: upload-file.log added

upload file log

comment:1 by ianwallen, 12 years ago

Worked for me on latest nightly build.

There have been a lot of updates since 2.8.0RC0 - may want to try the current nightly build to see if the issue exists.

comment:2 by landry, 12 years ago

Forgot to say this was with the widgets/extjs gui, if that can matter. I'll retry with a fresh build from 2.8.x branch.

comment:3 by landry, 12 years ago

Resolution: worksforme
Status: newclosed

Right, after pulling from the 2.8.x branch and rebuilding, resources.del.new correctly removes the file from the datadir, and unhooks it from the xml.

There's still a GET /geonetwork-private/srv/fre/resources.get?id=253&fname=&access=public without fname set that triggers a 500 code and a BadParameterEx exception, but i suppose that's not a big deal. closing the ticket.

comment:4 by landry, 12 years ago

Resolution: worksforme
Status: closedreopened

I've been able to reproduce the issue with 2.8.0rc2 - will try to go deeper to find the root cause and the exact steps to reproduce.

Note: See TracTickets for help on using tickets.