Task #6905 (closed)
Bug: delete script
Reported by: | jburel | Owned by: | jamoore |
---|---|---|---|
Priority: | critical | Milestone: | OMERO-4.4.4 |
Component: | Services | Version: | n.a. |
Keywords: | n.a. | Cc: | |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | 0.0d |
Sprint: | 2012-08-28 (3) |
Description
Currently the !deleteScript method throws an exception when attempting to delete an official script
Change History (17)
comment:1 Changed 13 years ago by jmoore
comment:2 Changed 13 years ago by jburel
- Milestone changed from OMERO-Beta4.3.3 to OME-5.0
Pushing. Just noticed the problem while working with the "edit" method
comment:3 Changed 13 years ago by jmoore <josh@…>
(In [4b9d827109fd5677247dc495610304d89baeb306/ome.git]) Failing testDelete6905 (See #6905)
comment:4 Changed 12 years ago by jmoore
Waiting on 3532-chgrp branch.
comment:5 Changed 12 years ago by jmoore
- Remaining Time set to 1.0
- Sprint set to 2012-06-19 (17)
- Status changed from new to accepted
comment:6 Changed 12 years ago by jmoore
- Priority changed from critical to major
comment:7 Changed 12 years ago by jburel
- Sprint changed from 2012-06-19 (17) to 2012-07-03 (18)
Moved from sprint 2012-06-19 (17)
comment:8 Changed 12 years ago by jburel
- Sprint changed from 2012-07-03 (18) to 2012-07-17 (19)
Moved from sprint 2012-07-03 (18)
comment:9 Changed 12 years ago by jmoore
- Milestone changed from OMERO-Beta4.4 to OMERO-Beta4.4.1
- Priority changed from major to critical
- Sprint 2012-07-17 (19) deleted
Even on the 6905-delete-refactoring branch, this isn't going to be possible without further work. Just running "bin/omero delete /OriginalFile:1" fails with:
2012-07-06 09:09:42,076 INFO [ ome.services.graphs.GraphState] (2-thread-3) Failed to process OriginalFile: 451 due to ConstraintViolation: fkjoboriginalfilelink_child_originalfile
We'll have to make a decision about the graph spec for original files and add more tests.
comment:10 Changed 12 years ago by jmoore
- Sprint set to 2012-08-28 (3)
Note: this is a similar problem to being able to null fileannotation.file when deleting the original file. (See #7314)
comment:11 Changed 12 years ago by jmoore
- Owner jmoore deleted
- Status changed from accepted to new
comment:12 Changed 12 years ago by jmoore
- Owner set to jmoore
- Remaining Time changed from 1.0 to 1
comment:13 Changed 12 years ago by jmoore
- Remaining Time changed from 1 to 0
- Resolution set to fixed
- Status changed from new to closed
Work available under https://github.com/openmicroscopy/openmicroscopy/pull/310
comment:14 Changed 12 years ago by jmoore <josh@…>
(In [d6983a76d18437f880f4237c75344207f9eb3716/ome.git] on branch develop) Add stdout and stderr to launch output (See #6905)
This is useful for immediately deleting or downloading
the stdout and stderr files (i.e. during testing)
comment:15 Changed 12 years ago by jmoore <josh@…>
(In [c289d1d53453bdc190b1eb341bf79e46d3fa5d1b/ome.git] on branch develop) Permit deleting originalfiles that are linked to jobs (Fix #6905)
This uses the same technique as the fileannotation delete (#7314)
to delete the joboriginalfilelink if a file is linked to a job.
comment:16 Changed 12 years ago by jmoore <josh@…>
(In [a8e8d545093c2c9535c81030efa75103fdb803fc/ome.git] on branch develop) Refactor for ScriptI to use Deletion (See #6905)
Deletion instances are now provided by the Spring
context with the name "ome.services.delete.Deletion".
There is still work that could be done to make the
use of the object easier (start/execute/deleteFiles/stop).
Also enabled the "script delete" command for the CLI.
comment:17 Changed 12 years ago by jmoore <josh@…>
(In [2f5942e6ee37d3e6a7c14f907c87f36aa7a65b1d/ome.git] on branch develop) Use Deletion for official uploads as well (See #6905)
This would be best handled by refactoring the DeleteHandleI logic in order to make use of the new delete. I've already done the refactoring in the chgrp branch. Should we push this until 4.4?
In the mean-time, we could either throw another exception -- though the ValidationException which is currently being thrown is already an ApiUsageException -- or we could try to manually unlink the script from any of the jobs which have run it, though I'm not completely sure that's what we want to do.
Obviously, only an admin would be able to do this, but even then, would it be better to make this method just de-activate the script rather than delete the original file?