Duplicate Attachments

System
System Member Posts: 9
Why does Jama allow to add attachments to the project that are the same document, same name (title in Jama), and same exact description. Is there is a reason for this since my users are confused as many users are attaching the same document at the same time. Is there a way we can display a message or avoid duplicates?

Comments

  • [Deleted User]
    [Deleted User] Posts: 161
    edited September 2016
    Hi Rupa,

    That's an interesting question/suggestion. You are correct that Jama does not do any checking. Perhaps some inconvenient work-arounds are

    1) Post documents into Jama only by the Project Admin so he/she can quickly tell whether a file exists already by looking at the name, file size, or other Project Admins.
    2) Post your documents into other document repository. Get the URL links. Jama users then just post the links.
    3) I'm sure other users can chime in.

    Good luck.

    swoo

    image
  • [Deleted User]
    [Deleted User] Posts: 9
    edited April 2016

    I agree with Rupa. Jama should search for duplicate attachments within the project itself. If the name of the attachment, extension and description are the same, a message or warning should be displayed to avoid duplicates and manage server space wisely. 

    I noticed that when you delete an attachment from the project, the attachment is no longer visible in Jama but the file still exists in the server and it does not get deleted. I am not sure if this is because of indexing issues and all files need to be kept in the server but I can anticipate performance issues for on-premises customers.

    Thanks.

  • [Deleted User]
    [Deleted User] Posts: 911
    edited June 2016
    Rupa, this is a great question. I can explain the technical reason why Jama allows duplicates, but I'm not really sure about the philosophical reasons. I understand V's point that if the same attachment could be reused it would save server space. But on the other hand, I'm sure there is a use case for allowing attachments with the same name and filename.

    But as far as that technical reason goes, when you add an attachment Jama doesn't check the database for duplicate. (Consider, also, that Jama doesn't check for duplicates for much of anything—as you've probably encountered, you could name 900 Requirements the same thing, and I know there are use cases for that). The attachment is saved in the [contour home]/attachments directory with a numbered prefix. If you look in that folder, you'll see attachments that once had the same filename still do except for a numerical prefix. An entry is made in the database that then refers to that prefixed filename in the attachments directory.

    All I think this boils down to having abilities that suit *most* customers, and sometimes it ends up not being ideal. That said, I'll convert this Question to an Idea if you'd like, so that our Product team can consider it as such.
  • [Deleted User]
    [Deleted User] Member Posts: 5
    edited July 2017
    I've noticed that when an attachment is orphaned (removed from an item), that it is actually listed in the Attachments tab of the Project Configuration section as not being attached to anything.  I've been afraid to just delete the items though, even though the system shows that they are not attached to anything.  I assume if these are safe to delete, then that would alleviate some of the space concerns.  Does anyone know if it is ok to simply delete all of these?

    ------------------------------
    Henry Kwok
    The Ford Foundation
    ------------------------------
    -------------------------------------------
    Original Message:
    Sent: 06-22-2015 20:19
    From: VCarvajal LastName
    Subject: Re: Duplicate Attachments

    I agree with Rupa. Jama should search for duplicate attachments within the project itself. If the name of the attachment, extension and description are the same, a message or warning should be displayed to avoid duplicates and manage server space wisely. 

    I noticed that when you delete an attachment from the project, the attachment is no longer visible in Jama but the file still exists in the server and it does not get deleted. I am not sure if this is because of indexing issues and all files need to be kept in the server but I can anticipate performance issues for on-premises customers.

    Thanks.



  • @Henry, yes, it's safe to delete these. If you view the attachment in single item view, there's a tab that shows what item(s) it's attached to-you could always double-check there to ensure it's really an orphan.
    single item view of attachment
  • Cornelia Retsch
    Cornelia Retsch Member, Data Exchange Posts: 2
    edited October 2022
    Dear Kristina,

    even though accepting duplicates may have a use case, it would be nice to get a pop-up notification. Would that be an option to support all use cases (also those with restricted storage space)?

    BR, Cornelia

    ------------------------------
    Cornelia Retsch
    Saint-Gobain
    ------------------------------
    -------------------------------------------
    Original Message:
    Sent: 06-22-2015 18:32
    From: Kristina King
    Subject: Re: Duplicate Attachments

    Rupa, this is a great question. I can explain the technical reason why Jama allows duplicates, but I'm not really sure about the philosophical reasons. I understand V's point that if the same attachment could be reused it would save server space. But on the other hand, I'm sure there is a use case for allowing attachments with the same name and filename.

    But as far as that technical reason goes, when you add an attachment Jama doesn't check the database for duplicate. (Consider, also, that Jama doesn't check for duplicates for much of anything-as you've probably encountered, you could name 900 Requirements the same thing, and I know there are use cases for that). The attachment is saved in the [contour home]/attachments directory with a numbered prefix. If you look in that folder, you'll see attachments that once had the same filename still do except for a numerical prefix. An entry is made in the database that then refers to that prefixed filename in the attachments directory.

    All I think this boils down to having abilities that suit *most* customers, and sometimes it ends up not being ideal. That said, I'll convert this Question to an Idea if you'd like, so that our Product team can consider it as such.