Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-13344

Resolve test / schema issues around prefix_id, suffix_id, gender

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.4.0
    • Fix Version/s: 4.4.0
    • Component/s: None
    • Labels:
      None

      Description

      Am opening a JIRA ticket on this so we have a track of our discussions. As I understand it tokens currently use the syntax

      {individual_prefix}

      {individual_suffix}

      {gender}

      and profiles have field names with those same names (in the database). Updates to the handling of these fields broke this handling & since then we have been playing whack-a-mole to fix. Kurund also mentioned 'search' being affected - but I don't know the context of that.

      Options are

      1) run updates on the database in this upgrade script. The risk is we might miss some (the advantage is reduction of technical debt)

      OR

      2) ensure the BAO Query object continues to accept the 3 above fields as return properties, input params & output params.

      On the tokens side I am unclear as to whether one or both of the token types are affected - ie. the type in smarty & the type in display_name etc

      Note that the current addition of uniquenames to the schema for these 3 fields is, as I understand it, in response to trying to address #2 above.

      The API Must continue to accept

      • suffix_id, prefix_id, gender_id, individual_suffix & individual_prefix as input params (integer or string)
      • it needs to continue to output the same things as under 4.3 & earlier.
        'gender_id' => '1,
        'gender' => ''F'',
        'prefix_id' => '2,
        'prefix' => 'Mrs',
        'suffix_id' => ''1,
        'suffix' => 'Jr',

      some asides -

      1) I would personally prefer to use the smarty style rendering in display_name etc - Antrik has introduced this on greetings & it seems a relatively small patch with a big improvement. However, we would need to upgrade DB values.

      2) I would personally like to see the storage names of profile fields in the uf_fields table more tightly match the schema as it would be much easier to generalise code if we could say 'all fields stored as having the entity 'Membership' can be passed to the membership api. I am doing some long-winded hacks in an extension that a tighter naming convention here would avoid.

        Attachments

        1. GenderPrefixImportTest.csv
          0.2 kB
          David Greenberg
        2. Screen Shot 2013-09-26 at 11.08.51 AM.PNG
          24 kB
          David Greenberg
        3. Screen Shot 2013-09-30 at 12.11.57 PM.PNG
          185 kB
          David Greenberg

          Issue Links

            Activity

              People

              • Assignee:
                colemanw Coleman Watts
                Reporter:
                eileen Eileen McNaughton
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: