CRM-12706 export: custom field labels, not values, are exported

    Details

    • Type: Bug
    • Status: Won't Do
    • Priority: Major
    • Resolution: Won't Do
    • Affects Version/s: 4.3.3
    • Fix Version/s: Unscheduled
    • Component/s: Core CiviCRM
    • Labels:
      None
    • Versioning Impact:
      Patch (backwards-compatible bug fixes)

      Description

      create a custom field such as a radio or checkbox where the option labels are different from the values.
      add/edit contacts and use that field. conduct a search and export the results.

      the export file exports the field labels – not the field values, as was expected.

        Attachments

          Activity

          [CRM-12706] export: custom field labels, not values, are exported
          Donald A. Lobo added a comment -

          ideally we should export both since both have their needs in various scenarios

          Brian Shaughnessy added a comment -

          just working through this on the import side of the equation –

          interestingly, we do a value check in the parser (CRM/Import/Parser/Contact.php) around line 1208, where we compare the data in the import file with both the value and label of the custom field (I'm looking at radio button types specifically). and if the incoming data matches either, we allow the parser to continue.

          the problem is that we simply take whatever data we're given and import that – even if it's the label, not the value. consequently the data in the table is the label, not the value, and so it isn't stored or displayed correctly. I'm looking into where that's handled now.

          Brian Shaughnessy added a comment -

          so the issue works its way back to CRM_Core_BAO_CustomField::formatCustomField()

          the question I have is whether we want to support dual handling only during import, or whether we want to look at supporting it more broadly. in other words – should we allow labels as valid data (which are then converted to values on insert) only during the import process, or is that something we also permit elsewhere (e.g. API actions).

          Brian Shaughnessy added a comment -

          proposed fix:
          http://paste.org/64957

          this would only affect the import process

          David Greenberg added a comment -

          The patch doesn't seem to address the problem described in the issue. If you can provide a PR for the export issue, we can push back to 4.4.

          Eileen McNaughton added a comment -

          I'm closing this unless someone wants to re-test / provide 4.7.x instructions to replicate. As this is nearly 5 years old it is likely fixed just not updated.

            People

            • Assignee:
              Brian Shaughnessy
              Reporter:
              Brian Shaughnessy

              Dates

              • Created:
                Updated:
                Resolved: