Erik,

I can't duplicate this bug.  Can you please tell me how you managed to set it up?

For reference, this is what I tried:

1. From a clean development site.
2. Add a new article to /home, but do not commit it
3. Cut it to the clipboard
4. Go to Manage Clipboard
5. Select the checkbox and hit the delete button.
6. The Article was deleted with no problems.

Seems correct from your point. But the asset should be created by another user then the one trying to delete

(same case as when the "Move Clipboard to trash"
 workflow triggers).

I cant check this out by now, maybe if you got some time to try this? 

/erik 

Okay, that's the missing piece (another user).

Here's the procedure to repeat.

1. As some user, create an asset.  Do not commit it.
2. Cut/copy it to the clipboard.
3. Admin comes along.
4. Manages the system clipboard.
5. Tries to delete the asset.

Since the asset is not committed, it can't be instanced via newByDynamicClass without a specific revisionDate, so Asset->newByDynamicClass returns undef and then eventually undef->method gets called.

I don't know if this can be fixed.  We might have to live with trapping the error and letting you know that the asset must be committed before being deleted.  I'll have to check with JT. 

JT said the right fix is not to display the Asset in the Clipboard unless it's committed, or in your version tag.

If it becomes a big issue, Admin should be able to set the version tag to be their own and then move it to the trash manually.

Fixed in 7.3.12 

It is not an big issue, but please confirm that the "Move asset to trash" workflow wont bail and exit when running into one of these assets! 

/Erik 

I hand tested the TrashClipboard activity by running the workflow.  With an uncommitted Asset, no warnings or errors and the Asset was not Trashed.  With a committed Asset, it Trashed it.