Gliffy

After removing a gliffy diagram, the actual underlying attachment is still there

Details

  • Description:
    Hide

    Steps to reproduce:

    1) Use the "Remove" link underneath a gliffy diagram and remove it
    2) go to the attachments tab
    3) you will still find the attachment is still there

    There is no reason why the attachment object should still be around if the diagram has been removed.

    When an attempt is made to manually remove this attachment, the following error is displayed:

    You cannot view this page due to inherited restrictions

    Page level restrictions have been applied to a parent of the current page. These restrictions limit access to only certain certain user(s) or group(s) and apply to all pages in the hierarchy underneath the parent.

    This does not make sense considering this is a vanilla page with no parent pages or any page level restrictions on it.

    Show
    Steps to reproduce: 1) Use the "Remove" link underneath a gliffy diagram and remove it 2) go to the attachments tab 3) you will still find the attachment is still there There is no reason why the attachment object should still be around if the diagram has been removed. When an attempt is made to manually remove this attachment, the following error is displayed:
    You cannot view this page due to inherited restrictions Page level restrictions have been applied to a parent of the current page. These restrictions limit access to only certain certain user(s) or group(s) and apply to all pages in the hierarchy underneath the parent.
    This does not make sense considering this is a vanilla page with no parent pages or any page level restrictions on it.

Activity

Hide
David Loeng added a comment - 14/Jan/08 10:58 PM

This is the erorr you get when you attempt to remove the attachment manually.

Show
David Loeng added a comment - 14/Jan/08 10:58 PM This is the erorr you get when you attempt to remove the attachment manually.
Hide
David Loeng added a comment - 14/Jan/08 11:07 PM

Tested on Confluence 2.7 with Gliffy plugin 1.3.5

Show
David Loeng added a comment - 14/Jan/08 11:07 PM Tested on Confluence 2.7 with Gliffy plugin 1.3.5
Hide
Lou Trimarco added a comment - 11/Apr/08 1:12 PM

Hi Chris....

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

Show
Lou Trimarco added a comment - 11/Apr/08 1:12 PM Hi Chris.... 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
Hide
Chris Kohlhardt added a comment - 28/Apr/08 8:44 AM

The most likely cause of this issue is permissions.

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

Show
Chris Kohlhardt added a comment - 28/Apr/08 8:44 AM The most likely cause of this issue is permissions. 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
Hide
Chris Kohlhardt added a comment - 06/May/08 7:42 AM

OK, I was confused on this one momentarily.

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.

Show
Chris Kohlhardt added a comment - 06/May/08 7:42 AM OK, I was confused on this one momentarily. 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.
Hide
Chris Kohlhardt added a comment - 08/May/08 1:25 PM

Response to Shannon's email:

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?

Show
Chris Kohlhardt added a comment - 08/May/08 1:25 PM Response to Shannon's email:
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?
Hide
Shannon Krebs added a comment - 08/Jun/08 6:12 AM

Remove action has been updated to remove macro if on the same page as diagram.

Show
Shannon Krebs added a comment - 08/Jun/08 6:12 AM Remove action has been updated to remove macro if on the same page as diagram.

People

Dates

  • Created:
    14/Jan/08 10:57 PM
    Updated:
    09/Oct/08 12:56 PM
    Resolved:
    08/Jun/08 6:12 AM