1. 13 Oct, 2013 2 commits
  2. 12 Oct, 2013 2 commits
  3. 11 Oct, 2013 4 commits
    • Olaf Buddenhagen's avatar
      Make all Individual name fields configurable · 8b49cb50
      Olaf Buddenhagen authored
      Adding a third block to the 'contact_edit_options' setting, to allow
      controlling which of the various name fields (prefix, formal title,
      first name, middle name, last name, suffix) show up on the contact edit
      forms. (Both main form and quick edit of the contact name.)
      For now, the name fields can only be enabled or disabled; there is no
      support for changing the order in which they appear on the edit forms.
      While this could be handled trivially in the configuration UI (the code
      is already there for the other parts of 'contact_edit_options'), it
      would require a major change to how the actual name edit forms are
      constructed -- and I'm not even sure there is an actual use case for
      Note: This change doesn't affect the Display Name -- that one is still
      configured using the token-based template.
      Also, it doesn't affect all the other places where name fields are used
      (soft credits, honoree, billing contacts etc.): there are way too many
      of them, each implemented separately (and inconsistently). Again, the
      way forward seems to be centralising all name field handling in a common
      piece of code, and invoking that in all places dealing with Individual
      name fields...
      After merging this, sql/civicrm_generated.sql needs to be regenerated,
      to pick up the new option values and default setting.
    • Olaf Buddenhagen's avatar
      Revert "Make `formal_title` field optional" · b890bee3
      Olaf Buddenhagen authored
      This reverts commit 5b5217d7.
      In preparation for more generic name field configurability.
    • vivekarora's avatar
    • kurund's avatar
      Merge pull request #1776 from monishdeb/CRM-9988 · ca70ab3a
      kurund authored
      CRM-9988 fix - Panama in Africa West, East, Central and Southern region
  4. 10 Oct, 2013 1 commit
  5. 09 Oct, 2013 9 commits
    • kurund's avatar
      Merge pull request #1457 from sfe-ev/greetings-PR · dbf6f574
      kurund authored
      Improving International Name and Greetings handling
    • kurund's avatar
      Merge pull request #1751 from elcapo/master · 257ef280
      kurund authored
      Change assignation in log of changes made via API (CRM-13549)
    • kurund's avatar
      Merge pull request #1756 from tttp/crm-13552-crmAPI · 1e601a45
      kurund authored
      CRM-13552 add a smarty error if there is a crm error in {crmAPI}
    • kurund's avatar
      Merge pull request #1760 from ravishnair/CRM-10347 · 0bd68b3a
      kurund authored
      -- CRM-10347 added birth date columns and filters
    • Olaf Buddenhagen's avatar
      Add configuration UI for Communication Style options · d4311a7a
      Olaf Buddenhagen authored
      Add a page in the Communication Preferences, using the generic Option
      The menu entry is added above the entries for Email Greeting Formats,
      Postal Greeting Formats, and Addressee Formats, just like in the actual
      contact forms and views.
    • Olaf Buddenhagen's avatar
      Introduce new `communication_style` field for Contacts · aa62b355
      Olaf Buddenhagen authored
      Add new field in the Communication Preferences block, mostly for driving
      the new conditional greeting templates. (Though other uses are
      possible of course.)
      The Communication Style field is implemented as radio buttons defined
      through an option group (pseudoconstant), similar to the Gender field.
      Unlike Gender, it has a default value assigned automatically for new
      The field is placed just above the Email Greeting, Postal Greeting, and
      Addresse controls, as it's meant to be used as a kind of master switch
      driving the various greeting templates. Just like the Prefix/Suffix
      fields in the name block for Individual contacts, the Communication
      Style field is automatically hidden from all forms and views if no
      option values are defined for the field.
      The database field comes with an index, like all(?) pseudoconstant
      fields. Presently the index is not used much (probably the only place
      being deletion of existing option values); but this is likely to change
      when more functionality is added around this field in the future.
      (Search etc.)
      The handling of the new field throughout the CiviCRM code base should be
      mostly complete. We deliberately punted on some of the obvious, larger
      pieces of functionality (search, import, profiles) for now, as they
      would require considerable additional effort, so we treat them as extra
      features to be implemented seperately upon need. We tried to be complete
      with all smaller bits (mostly by grepping for `gender`, which requires
      similar handling in most places...); but we might have omitted some,
      and/or done some that aren't actually necessary -- it's rather hard to
      tell sometimes what a particular piece of code is all about...
    • Olaf Buddenhagen's avatar
      Make `formal_title` field optional · 5b5217d7
      Olaf Buddenhagen authored
      Add a config setting to make display of the Title input field (in
      contact edit forms) optional.
      (This doesn't affect contact view, as the name displayed there is
      determined by the "Individual Display Name Format" template instead.)
      This is a minimal approach, adding just the title setting. Perhaps it
      might be preferable to add a full set of options for disabling the other
      name fields as well, while at it?...
      (We are willing to do that too, as it shouldn't be too hard, and we have
      users for that as well -- but we need some consensus about the right way
      for handling this.)
      The setting is placed in the "Display Preferences", next to the
      "Individual Display Name Format". However, it could be placed next to
      "Editing Contacts" (also in "Display Preferences") as well -- it's
      somewhat related to both...
    • Olaf Buddenhagen's avatar
      Introduce new `formal_title` field for contacts · e171748b
      Olaf Buddenhagen authored
      For Individual contacts, add a Title field along with the other name
      fields. This one sits between the Individual Prefix and First Name
      fields, which is the right place for academic and other formal titles
      (not only) in Germany.
      It is a free-form text field, as there are way too many obscure titles
      and possible combinations of titles for any kind of exhaustive option
      list. Also, this field is generally not processed, but rather just
      included verbatim wherever the name is used -- so there is no real need
      for normalisation.
      Note: The field is conditional in the templates, but it's added
      unconditionally at PHP level in this commit. That's because we don't
      know yet how to handle the configuration best. A followup commit
      implements one possible variant for the configuration.
      In the actual input form, the field is labled with just 'Title', as it
      should be clear enough in this context that it's about a formal title;
      and a shorter name seems more convenient... However, we are wondering
      whether this doesn't introduce additional confusion?
      This commit is mostly only covering the main contact screen. (And some
      other generic bits, such as exportable fields etc.) There are various
      other places dealing with name fields (especially for billing contacts
      and honoree) -- each one implementing it individually (and thus rather
      inconsistently...) in a hard-coded fashion. Adapting all of these will
      be a crazy amount of work, so we are punting this for now...
      (The Right Thing To Do (TM) probably would be implementing some central
      name handling code to use everywhere.)
      With this commit, the definition of the existing `prefix` field is also
      slightly changed regarding the import heuristics, to reflect the fact
      that titles are no longer supposed to be stored in the `prefix` field.
    • Olaf Buddenhagen's avatar
      Process greeting templates with Smarty · 73d64eb6
      Olaf Buddenhagen authored
      When expanding `email_greeting`, `postal_greeting`, and `addressee`
      templates, after substituting the CiviCRM tokens, pass the result
      through Smarty.
      This way it becomes possible to include conditionals (or other types of
      fancy processing) in greeting templates. Example:
        {capture assign=style}{contact.communication_style}{/capture}
        {capture assign=prefix}{contact.individual_prefix}{/capture}
        {if $style=="Familiar"}
          {if $prefix=="Frau"}
          {elseif $prefix=="Herr"}
          {if $prefix=="Frau"}
            Liebe Frau
          {elseif $prefix=="Herr"}
            Lieber Herr
            Liebe/r Herr oder Frau
          {contact.formal_title} {contact.last_name}
      The major limitation of this approach is that the `label` field -- where
      the actual greeting templates are stored -- is limited to 255
      characters. (So the above example wouldn't actually work without some
      trickery to make it shorter...) Not sure how to address this problem.
      We are wondering whether we should hide this feature behind a config
      option, like it is done for Mailings? I'm not sure this is really
      necessary here, as the Smarty processing shouldn't be in anyone's way
      when unused. The only possible downside is that templates with syntax
      errors might produce somewhat obscure warnings or errors in some cases.
      However, the greeting templates are generally only set up during the
      implementation phase, and never touched by mortal users -- just like
      system workflow message templates, which use Smarty unconditionally as
      well. Also, it feels wrong to hide such useful functionality behind some
      obscure option...
      To allow for proper Smarty escaping, this patch needs to introduce some
      small changes to the way contact tokens are processed in the greetings.
      These shouldn't affect other callers.
      To avoid code duplication, a new function is introduced for the template
      processing (tokens+Smarty), adding another layer of indirection. This
      could be avoided, if replaceGreetingTokens() wasn't used in other
      contexts too. (Which I believe is a misunderstanding: I'm pretty sure
      the function was only meant for *generating* the greeting texts, by
      replacing tokens in the greeting templates when saving a contact record;
      and not for replacing greeting tokens in message templates -- the latter
      should be handled just fine along with the other contact tokens...)
  6. 08 Oct, 2013 2 commits
  7. 07 Oct, 2013 2 commits
  8. 06 Oct, 2013 11 commits
  9. 05 Oct, 2013 1 commit
  10. 04 Oct, 2013 1 commit
  11. 03 Oct, 2013 4 commits
  12. 02 Oct, 2013 1 commit