My organization is just getting started using wiki and I've been experimenting with Gliffy. I encountered this same problem, but was able to find a workaround that may help in finding a permanent fix.

If you go to the attachment page and EDIT the unwanted diagram (even though the warning tells you not to), you can then click the OK button at the bottom of the screen to get back to the attachment page. I was then able to REMOVE the diagram without getting the error panel.

Hope this helps.

Lou Trimarco

Please ask an administrator to check the permissions of the space that is experiencing this issue.

• Navigate to Browse Space->Space Admin->Permissions
• For the user who is having trouble with removing attachments, please verify that the user has the 'Remove' privilege for Attachments on the permissions page.

Please let me know if this issue is still a problem after you investigate permissions.

thanks!

-chris

Originally we didn't deleted the actual attachment because I was worried people would accidentally delete diagrams and not be able to recover them. I just testing this out, however, and it turns out you can recover removed attachments using the history / restore revision of a page. Since this works pretty good, I think it's safe to remove the underlying attachment.

In terms of the original issue about deleting attachments there are a
few things to consider. Since the page edits and removing attachments
are two different permissions I think there should be a checkbox or
radio button with options to delete macros in page, diagram attachment
or both. These could be selectively enabled depending on the users
permissions.

Generally speaking, I'd rather avoid giving users too many options to choose from as this might create confusion.

The whole point of keeping the attachment around after deleting a diagram was to make sure that there was a way to restore the diagram.

A few thoughts:

• There really is no value to only deleting the attachment, as a new blank diagram will automatically be created the next time the {gliffy} macro is rendered.
  - If we give the user the ability to ONLY delete the {gliffy} macro, the user would need to know that they have to create a new {gliffy} macro using the name of the attachment to restore the diagram. I don't think this is very obvious to the user, where as using the page history to restore the document seems more consistent with the way to restore other content in Confluence pages.
  
  

  Also a problem with deleting the attachments is they could be being
  used from another page, you have no way of knowing, I guess thats just
  up to the user.

  
  
  If we wanted to be really careful, we might be able to use the search system in Atlassian to look for references to the attachment being deleted. Can you look into this?
  
  

  Another thing I was thinking about was do we even need the delete
  action at all, users are able to delete the macro markup and
  attachment from the page themselves anyway, why not just encourage
  them to use the normal wiki functionality rather the try to replicate
  it ?

  
  
  The 'Remove' action was actually a feature requested by a customer. I do think it enhances usability, since there are actually two steps required, in this exact order: 1) Delete the {gliffy} macro 2) Delete the related attachment.

thoughts?