• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.

      The fact it isn't one means that in all sorts of different parts of our code, we have to put special cases for attachments, which is silly. It's also making labeling of attachments rather difficult.

      Note: Right now, ContentEntityObjects all have attachments. This might need to be changed, since an Attachment can't really itself has an attachment. On the other hand, if it doesn't hurt, we may as well not go through the pain of adding another layer of inheritance there.

            [CONFCLOUD-3962] Turn Attachment into a ContentEntityObject

            This is due to be released in Confluence 5.7. For more information, see:
            https://developer.atlassian.com/display/CONFDEV/Preparing+for+Confluence+5.7

            Niraj Bhawnani added a comment - This is due to be released in Confluence 5.7. For more information, see: https://developer.atlassian.com/display/CONFDEV/Preparing+for+Confluence+5.7

            Why not subclass ContentEntityObject and just make AttachmentEntityObject a special case where it only allows a single attachment, doesn't allow markup but instead renders some default content representing the attachment (ideally for things like Word documents this could actually be a web view of the document itself, possibly wrapped with some controls for uploading a new version, changing the comment, etc), throws an exception if you try to add a second attachment to it, etc. While it's a bit of an OO hack, it should work and resolve this issue, which is a big hurdle to using Confluence as a document repository.

            Jim LoVerde added a comment - Why not subclass ContentEntityObject and just make AttachmentEntityObject a special case where it only allows a single attachment, doesn't allow markup but instead renders some default content representing the attachment (ideally for things like Word documents this could actually be a web view of the document itself, possibly wrapped with some controls for uploading a new version, changing the comment, etc), throws an exception if you try to add a second attachment to it, etc. While it's a bit of an OO hack, it should work and resolve this issue, which is a big hurdle to using Confluence as a document repository.

            Is there a need to prevent Attachments having Attachments ... just don't provide a UI for it? (like SpaceDescriptor has no UI for attaching, but you can attach to it using the API)

            Of course anyone doing that on the API would be silly - or insane ... the API doesn't generally try to protect people from themselves elsewhere - at least to my knowledge.

            Dan Hardiker added a comment - Is there a need to prevent Attachments having Attachments ... just don't provide a UI for it? (like SpaceDescriptor has no UI for attaching, but you can attach to it using the API) Of course anyone doing that on the API would be silly - or insane ... the API doesn't generally try to protect people from themselves elsewhere - at least to my knowledge.

              nbhawnani Niraj Bhawnani
              cmiller@atlassian.com Charles Miller (Inactive)
              Votes:
              15 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: