Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-64464

Provide the ability to CSV import comment based on the its visibility

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • 2
    • 4
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

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

      At the moment, CSV importer only allows comments to be mapped to comment body and it is not possible to maintain the visibility of the comments. For example, the comment belongs to a Service Desk issue and it is an internal comment. After the import, the comment will be automatically set to public.

      Thus, it would be great if CSV importer can provide an option to set the visibility of the comment during the mapping field process.

            [JRASERVER-64464] Provide the ability to CSV import comment based on the its visibility

            Most of the customers that are migrating from external systems into JSM use private comments, we need to have this feature to accommodate these migrations. This should be built-in in the JSM product!

            Italo [Modus Create] added a comment - Most of the customers that are migrating from external systems into JSM use private comments, we need to have this feature to accommodate these migrations. This should be built-in in the JSM product!

            I consider this a bug.

            At present this lack of option is well on the way to prevent us from migrating to Jira Service Desk. I can format to other data types – does anyone have a way to import a comment with body, author, create date, and visibility set?

            Wesley Jones added a comment - I consider this a bug. At present this lack of option is well on the way to prevent us from migrating to Jira Service Desk. I can format to other data types – does anyone have a way to import a comment with body, author, create date, and visibility set?

            Ben Mann added a comment -

            While we also used the db workaround, the problem remains that there's still a period after the CSV import when private comments are visible. Because transition of a big servicedesk from an external system typically cannot occur overnight (ours contains millions of rows, and the old system must remain up until the changeover, requiring incremental imports), there remains a chance customers will be able to access damaging comments before those comments can be made internal again.

            Mitigating this risk - without incurring expensive, tedious workarounds - would also help us represent servicedesk in a positive manner to our stakeholders during what should be the final stages of our evaluation.

            Ben Mann added a comment - While we also used the db workaround, the problem remains that there's still a period after the CSV import when private comments are visible. Because transition of a big servicedesk from an external system typically cannot occur overnight (ours contains millions of rows, and the old system must remain up until the changeover, requiring incremental imports), there remains a chance customers will be able to access damaging comments before those comments can be made internal again. Mitigating this risk - without incurring expensive, tedious workarounds - would also help us represent servicedesk in a positive manner to our stakeholders during what should be the final stages of our evaluation.

            This is a more serious issue as inability to retain customer request visibility may lead to exposure of potentially sensitive information. Here is a couple of real-life use cases:

            1. Exporting JSD data with subsequent import into another JSD (with a drastically different configuration, so project configurator can't be used) exposes internal comments to customers, which is unacceptable.
            2. Importing non-JSD data from another system (e.g. Salesforce) does not provide an option to set the flag either.

            Basically, this is a serious enough issue to make CSV import into JSD a non-starter for many teams.

             

            I did find a workaround that seems to do the trick, but it's more of a hack anyway:
             
             

            • Identify comment IDs for all the comments that need to be set to Internal. I did this by cross-referencing Issue Key/Timestamp/Author of the comments in jiraaction and Source data.
            • Look up SEQ_ID for 'EntityProperty' in SEQUENCE_VALUE_ITEM
            • Construct a set of queries to add comment visibility setting for each comment ID:
              insert into entity_property values (408012,'sd.comment.property',1010336,'sd.public.comment','2016-08-10 14:17:58','2016-08-10 14:17:58','{"internal":true}');

              (first parameter needs to be higher than SEQ_ID in the previous step, with an increment for each line; third parameter is the comment ID from jiraaction, then there are created/updated dates)

            • Run the insert queries
            • Update SEQ_ID for 'EntityProperty' in SEQUENCE_VALUE_ITEM to exceed the Max of ID inserted into entity_property.
               
              Naturally, this approach is still fairly tedious as it requires quite a bit of data manipulation in Excel as well as an 'insert' DB hack, which is less than ideal, but it surely beats a manual fix for thousands of internal comments.
               

            Artem Fomin added a comment - This is a more serious issue as inability to retain customer request visibility may lead to exposure of potentially sensitive information. Here is a couple of real-life use cases: Exporting JSD data with subsequent import into another JSD (with a drastically different configuration, so project configurator can't be used) exposes internal comments to customers, which is unacceptable. Importing non-JSD data from another system (e.g. Salesforce) does not provide an option to set the flag either. Basically, this is a serious enough issue to make CSV import into JSD a non-starter for many teams.   I did find a workaround that seems to do the trick, but it's more of a hack anyway:     Identify comment IDs for all the comments that need to be set to Internal. I did this by cross-referencing Issue Key/Timestamp/Author of the comments in jiraaction and Source data. Look up SEQ_ID for 'EntityProperty' in SEQUENCE_VALUE_ITEM Construct a set of queries to add comment visibility setting for each comment ID: insert into entity_property values ( 408012 ,'sd.comment.property', 1010336 ,'sd.public.comment','2016-08-10 14:17:58','2016-08-10 14:17:58','{"internal":true}'); (first parameter needs to be higher than SEQ_ID in the previous step, with an increment for each line; third parameter is the comment ID from jiraaction, then there are created/updated dates) Run the insert queries Update SEQ_ID for 'EntityProperty' in SEQUENCE_VALUE_ITEM to exceed the Max of ID inserted into entity_property.   Naturally, this approach is still fairly tedious as it requires quite a bit of data manipulation in Excel as well as an 'insert' DB hack, which is less than ideal, but it surely beats a manual fix for thousands of internal comments.  

              Unassigned Unassigned
              nhassan Nur Asnida Hassan (Inactive)
              Votes:
              57 Vote for this issue
              Watchers:
              36 Start watching this issue

                Created:
                Updated: