Skip to main content
V
vkocsis1-Visitor
1-Visitor
July 26, 2016
Question

im issues --fields with same display name

  • July 26, 2016
  • 4 replies
  • 6222 views

Hello!

I'm writing a small tool around "im" and its functionality. I ran into the following problem:

I have an issue type where there exists a field with the display name of "Type". By default there is the built in field "Type". The field's name is different, lets call it "Other_Type".

I'm trying to get an issue with the following command:

im issues --fields=Type,Other_Type issue_id

The problem is that no matter what I do it only returns the later field (Other_Type). If I use --fields=Other_Type,Type then it only returns "Type". I tried it with the column numbers (eg -10 and 500) but nothing changed.

How can I get both fields in one call to "im"? I rather not call "im" twice due to runtime requirements. Changing the display name is not an option.

Thanks,

Viktor

    4 replies

    D
    DanR.1-Visitor
    1-Visitor
    July 26, 2016

    Possible suggestion/solution.  Add --fieldsDelim=XYZ (or whatever you want to call it) and redirect the output to a text file.

    im issues --fields=Type,Other_Type,id --fieldsDelim=XYZ > c:\output.rtf

    Open the output.rtf and do a replace of the characters "XYZ" to whatever you want.  Tabs would be best IMHO.

    Hope that helps.

    Dan

      V
      vkocsis1-VisitorAuthor
      1-Visitor
      July 26, 2016

      Already tried using a custom delimiter character but the results are the same.

      Viktor

        K
        KaelLizak16-Pearl
        16-Pearl
        July 26, 2016

        Hello Viktor Kocsis‌,

        If you run im issues issue_id, do you get results for both the fields Type and Other_Type?

        Are those the actual names of the fields, or have you renamed them for this post?

        What is the output you get when you run im viewissue issue_id ?

        Regards,
        Kael

          V
          vkocsis1-VisitorAuthor
          1-Visitor
          July 27, 2016

          Hello!

          im issues issue_id : (without --fields) just returns the issue_id and Type as expected where Type is the (correct) issue Type.

          im viewissue issue_id: only returns Other_Type as "Type" where there is a conflicting display name between fields, if there is not it returns the actual issue Type.

          Type is the built in issue type (every issue have it) with the display name "Type".

          Other_Type is our custom field with the display name "Type".

          No, Other_Type is not the actual name, but I think it does not matter what the database name is (its unique after all). I tried using the database ID-s instead of field names but that results in the same.

          The strangest thing is that im issues --field Type,Other_Type only returns one field not two.

          If I use the webservice (Integrity_10_2Service) it returns the values correctly.

          Thanks,

          Viktor

            K
            KaelLizak16-Pearl
            16-Pearl
            August 2, 2016

            Hello Viktor Kocsis‌,

            Because the strings used might matter.  It looks like you're saying your custom field's name has the string "Type" in it, though.

            Which release of Integrity are you on?  I can't reproduce this behavior on 10.9.  When I try to set the display name to my equivalent of Other_Type on this release, I get the error "Error editing field AType:  MKS1038808: Cannot change display name to "Type" because type "Widget" already refers to a field with that display name.

            The code path might also depend on the kind of field.  Could you share what the type is for field "Other_Type"?

            Regards,
            Kael

              S
              skamaraj11-Garnet
              11-Garnet
              July 27, 2016

              Hello Viktor,

              "Im Issues" always runs with the "Field name" and not with respect to "Display Name". For example if you want to extract "Text and State" fields means, you have to specify

              "im issues --fields=ALM_Text,State <item_ID> ; here "ALM_Text" is the field name and "Text" is just display name.

              Please check whether you have specified valid "Field name" for both "Type" and "Other Type".

              Regards,

              Sathish

                V
                vkocsis1-VisitorAuthor
                1-Visitor
                July 27, 2016

                Hello

                I didn't used the display name as a parameter, I use the field name. If I would use the displayname, that would look like im issue --fields=Type,Type

                Also, its not possible to use it with the display name, it returns "Field "xyz" does not exist" error even if such display name exists but no field with that name.

                Please read the original post again.

                Viktor

                  D
                  DanR.1-Visitor
                  1-Visitor
                  July 27, 2016

                  Viktor,

                  I believe you should not use "Type" for the display name of the field "Other_Type".  Maybe change it to "Type2" or "Kind" or "Category".   When I name fields I place a tag in front of the field name.  For example:  I have three types called Problem Report (PR), System Change (SC) and Change Request (CR).  Fields created specifically for PR would be named "PR_MyFieldName", "SC_MyFieldName" and "SC_MyFieldName".

                  Dan

                    K
                    khoppe15-Moonstone
                    15-Moonstone
                    August 4, 2016

                    Hello,

                    I've had same problem and had been in contact with PTC Support.

                    They could verify this behaviour which is a bug.

                    Choosing fields with same Display name give the result like you see.

                    AFAIK an RfC had been created, but for me it is only low priority, cause we've used the workaround to change one field's display name.

                    Sorry that I can't give more details like the bug's RfC no.

                    Klaus

                      Terms & ConditionsAccessibility statement