Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Current »

Starting Release 8.2, Zephyr Enterprise documentation has moved from its current location on Atlassian to a dedicated, standalone Zephyr Enterprise Documentation page. Please see: https://support.smartbear.com/zephyr-enterprise/docs/en/zephyr-enterprise/zephyr-user-guide/test-repository/adding-a-test-case/about-adding-an-attachment.html

Consider the following conditions while adding a file as an attachment:

  • The default maximum file size is 50 MB.

  • The following file extensions are allowed:
    .7z, .bmp, .csv, .doc, .docx, .eml, .feature, .gif, .gz, .htm, .html, .jpeg, .jpg, .json, .key, .lic, .log, .m4p, .MHT, .mkv, .mp4, .msg, .odp, .ods, .odt, .pdf, .png, .pps, .ppt, .pptx, .py, .rar, .rtf, .sql, .svg, .tar, .txt, .wmv, .wrf, .xls, .xlsx, .xml, .yaml, .yml, .crt, .cer, .ca-bundle, .p7b, .p7c, .p7s, .pem, .keystore, .jks, .p12, .pfx, .pem, and .zip

  • The file MIME type should match the file extension.

    • To upload an unsupported file extension, zip it and attach it.

Configuring the File Size

The different ways to configure a file size in the system are:

You can configure the file size using the API endpoint and the method is PUT.

 /flex/services/rest/latest/admin/preference/admin

In the request body, the unit for the file size must be in bytes.
You must include the following parameters:

[  
 {
    "name": "allowed.upload.max.file.size",
    "value": "52428800"
 }
]

Internal Storage for Attachments

Attachments are stored in the attachment folder under Zephyrdata folder. The path to Zephyrdata folder can be found in jdbc.properties file saved under property ZEPHYR_DATA.

The folder Zephyrdata is a shared directory in case of a cluster setup as the data contained in this folder should be accessible to all the cluster nodes.

Attachment file and folder structure logic

The attachments are saved using the following logic:

attachment/<entityType>/seq-<sequenceId>/<entityId>/<attachmentId>

The placeholders occupied are:

  1. <entityType>: This is the type of entity against which the attachment is being saved.
    For example, testcase, requirement, user, and so on.

  2. <sequenceId>: This ID consists of 4 digits. The format consists of:
    <last four digits of entityId> + <padding count to 4 with 0>.
    For example,

    1. If the <entityId> is 1, then padding to make 4-digit count is 000, hence <sequenceId> is 1000.

    2. If the <entityId> is 34, then padding to make 4-digit count is 00, hence<sequenceId> is 3400.

    3. If the <entityId> is 12345, then padding to make 4-digit count is not required, hence <sequenceId> is 2345 as only the last 4 digits are taken.

  3. <entityId>: This is the ID of the entity against which the attachment is being saved.
    For example, testcaseId, requirementId, userId, and so on.

  4. <attachmentId>: This is the id given to every attachment as a unique identifier. This placeholder is the attachment file that was uploaded against the entity. The attachment is not saved with the original name in the directory but is saved with attachmentId.
    The following are the examples:

  • For a testcase with id 1, attachments will be found in the following path:

attachment/testcase/seq-1000/1/<attachmentFiles>

  • For a testcase with id 34, attachments will be found in the following path:

attachment/testcase/seq-3400/34/<attachmentFiles>

  • For a testcase with id 12345, attachments will be found in the following path:

attachment/testcase/seq-2345/12345/<attachmentFiles>

  • No labels