Details

    • Type: New Feature
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 4.6, 4.7
    • Fix Version/s: Unscheduled
    • Component/s: Core CiviCRM
    • Labels:
      None
    • Versioning Impact:
      Patch (backwards-compatible bug fixes)
    • Documentation Required?:
      User and Admin Doc
    • Funding Source:
      Needs Funding

      Description

      An organisation I've been working with uses Smart Groups in a way that I hadn't thought possible :

      • Organisation A is a customer of (= has a relationship with) organisation B. A smart group is created that contains all organisations like A that have such a 'customer' relationship.
      • A smart group is then created that contains all people who are a manager at organisations like A. This group contains 'all persons that have a 'manager' relationship with all organisations that have a 'customer' relationship with organisations like B'.
      • This group of managers is then automatically synced to a Drupal role using the civicrm_group_roles module. This works surprisingly well, except for some "can't sync back to smart group" errors.

      The problem that arises here is that refreshing the cache of the group that contains the managers, requires the group that contains their organisations to be filled first. Otherwise, the managers group will be empty and they will lose their permissions on the website.

      We're now working around this by 1) setting the smart group cache expiration time to 6 hours, 2) running job.group_rebuild every 4 hours from cron so the cache should never expire, and 3) making sure the managers group has a higher civicrm_group.id so it will be refreshed later than the groups it depends on. That (sort of) works. There are probably a lot of other possible ways to work around this: using a custom search, using custom fields that are updated regularly by an extension, etc.

      But this could perhaps be a very useful and powerful way to use smart groups, if scenarios like these were always handled correctly. For instance, there could be a field for every smart group where a user can specify group dependencies: smart groups that have to be updated before the current smart group can be updated. (Even better if this could be detected automatically.) If there are other organisations that use - or would like to use - smart groups in similar ways, we could see if we can make this possible as a collective effort.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              klevie Kevin Levie
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: