1. 11 May, 2019 2 commits
  2. 07 Apr, 2019 2 commits
  3. 05 Apr, 2019 4 commits
    • totten's avatar
      (NFC) Apply upcoming civicrm/coder policies (batch 1) · 0d48f1cc
      totten authored
      Method:
      
      * Checkout latest merged branch of civicrm/coder (`8.x-2.x-civi`)
      * Run this command to autoclean a batch of 100 files
       `PG=1 SIZE=100 ; find Civi/ CRM/ api/ bin/ extern/ tests/ -name '*.php' | grep -v /examples/ | grep -v /DAO/ | sort | head -n $(( $PG  * $SIZE )) | tail -n $SIZE | xargs phpcbf-civi`
      * Go through the diff. For anything that looks wonky, open in an editor and find a better solution
      
      Note: The automated checker makes good points about awkward indentation, but the automated cleanup often makes it
      worse.  So that's why I have to open it up.
      0d48f1cc
    • colemanw's avatar
      Short array syntax - auto-format CRM directory · be2fb01f
      colemanw authored
      be2fb01f
    • eileen's avatar
      Array syntax reformat on activity files · 96f94695
      eileen authored
      96f94695
    • eileen's avatar
      [REF] extract token functions · 86420016
      eileen authored
      This is an reviewer's commit from https://github.com/civicrm/civicrm-core/pull/12012/files
      
      We are about to merge array formatting changes that will make lots of PRs go stale.
      
      I couldn't get this reviewed & merged before the change but I thought if I could do it
      through a sub-commit it would be better than just making it go stale.
      
      This is a simple extraction & I will add merge on pass as it is a reviewer's commit
      86420016
  4. 28 Mar, 2019 1 commit
  5. 21 Mar, 2019 2 commits
  6. 15 Mar, 2019 2 commits
    • eileen's avatar
      --amend · 7f6e5735
      eileen authored
      Change-Id: Icea6f894d7a9e4656beae3cdb4cb5e44842b59b2
      7f6e5735
    • eileen's avatar
      Activity tab performance fix - switch to faster getActivities & getActivitiesCount · 6e793248
      eileen authored
      The getActivitiesCount & getActivities functions are faster & call permission hooks
      but we weren't able to switch to them until we resolved some performance issues
      (done) and resolved acl inconsistencies (resolved in 5.12) -we can do this now.
      
      From a performance POV the difference is tab-crashes vs tab resolves quickly
      on contacts with > 10k activities
      6e793248
  7. 13 Mar, 2019 1 commit
  8. 12 Mar, 2019 1 commit
  9. 05 Mar, 2019 1 commit
    • eileen's avatar
      Convert activity_date_time field to datepicker and add support for url input · 27cedb98
      eileen authored
      This converts the form to being a metadata defined field & a date-picker field as well
      as adding standardised url support for input.
      
      The input format is
      activity_date_time_high=20100101
      
      I stripped out the complex and probably broken based on feedback  & not used in core
      existing hard-coded url support.
      
      Note that there are some outstanding items
      1) the upgrade script item needs to be added - this includes dealing with renaming of the field
      since I made it more consistent
      2) I stripped out the check to ensure the high date is greater than the low date
      - if we still want this we should re-add as a generic thing. My guess is it's a bit optional
      27cedb98
  10. 28 Feb, 2019 1 commit
  11. 22 Feb, 2019 2 commits
    • mattwire's avatar
    • eileen's avatar
      Rationalise Activity api ACLs · cdacd6ab
      eileen authored
      We have a lot of inconsistency about how (and if) activity ACLs are applied. Note that permissions only apply
      when the api is being called with check_permissions = TRUE - e.g from the js layer.
      
      This PR changes the logic used for the activity.get api to be consistent with the report logic
      which
      a) is the most performant variant
      b) is the one with the least code complexity
      c) is more consistent with CiviCase
      d) allows hooks to modify the permissions applies
      e) creates consistency between api v3 & v4
      f) is consistent with some site user expectations but not others - the presence of all this inconsistency
      is an indicator not everyone wants the same thing but given that choosing a performant &
      maintainable option for core seems like a good criteria.
      
      After this patch
      1) the 'view all activities' permission will no longer by-pass all other ACLs. One could argue that's exactly
      what it means - but it doesn't do that in the UI which seems like the standard elsewhere.
      2) a user will be able to view an activity via the api if they have permission to view  ANY contact linked to it (before it was ALL contacts via the api)
      3) a user will not see the names of any contacts they do not have permission over when requesting activity contact details in return parameters
      4) getcount will no longer by-pass the api
      5) performance is improved
      
      Places where permissioning applies to activities
      - activities listing on contact - shows actitivies & related contact names regardless of permission to view the contacts
      - activity search results -- shows actitivies & related contact names regardless of permission to view the contacts
      - activity view page - links to view the activity exist on the above 2 screens but will give access denied unless they
      can see ALL related contacts
      - activity reports - shows activities if ANY related contacts are permitted, suppresses names of unpermitted contacts
      
      Potential follow on steps
      1) make the activity tab listing consistent by switching from the unperformant deprecatedGetActivities fn
      to the performance getActivities fn - there are no remaining blockers to that.
      2) align the activity view screen & add in hook call there too
      3) align activity search results screen, address performance issues there too....
      cdacd6ab
  12. 17 Feb, 2019 3 commits
  13. 11 Feb, 2019 2 commits
  14. 04 Feb, 2019 2 commits
    • Pradeep Nayak's avatar
      6e9c7c7e
    • eileen's avatar
      Performance fix for alternate getActivity listing function · 734f2683
      eileen authored
      We have an alternate function to render the activiy listing on the contact tab. It is
      getActivities whereas the other is deprecatedGetActivities.
      
      It was developed in order to replace the other and we have tests that compare the results of the 2. It is better in that it
      1) performs better (on a  WMF contact with many activities this is 'snappy' while the current deprecated one gives a  white screen time out) and
      2) calls the selectWhereClause hook, allowing hook alteration and respecting preferred architecture.
      
      However, we didn't go live with it in core because it
      1) has a remnant performance bugs (this PR fixes the last of these)
      2) implements ACLs differently - it uses generic functions whereas the deprecated one
      applies more limited permissioning. This is something to clarify & resolve separately.
      
      This PR fixes the last remaining performance issue - best described as
      'When one of the activities to be displayed has many targets the activity listing is slow to load'
      
      The reason for the slowness is that when 'target_contact_name' is passed to the api
      the api does a call for each contact to fetch the contact's sort_name. For a bulk mailing that went to 50,000 people that equates to 50,000 extra queries.
      
      However the actual display shows the first contact name and then gives a number for how many more should be retrieved. This PR hence does not ask the api for the display name, but rather does the check itself, but
      only for 1 target contact rather than ALL
      
      Note that a similar logic might be considered for assignee - I left that out of scope as I'm not
      aware of situations where a large number of assignees would be assigned to a single activity.
      
      The unit test ensures the output matches the deprecated function.
      734f2683
  15. 21 Jan, 2019 1 commit
  16. 14 Jan, 2019 1 commit
  17. 10 Jan, 2019 1 commit
  18. 09 Jan, 2019 1 commit
  19. 08 Jan, 2019 2 commits
  20. 02 Jan, 2019 1 commit
  21. 01 Jan, 2019 1 commit
    • eileen's avatar
      Fix activity.getcount function to filter out unpermitted activities. · ff2a3553
      eileen authored
      As part of an ongoing performance refactor of the activity.get api handling this extends the application of activity
      type filtering to the getcount function.
      
      The current methodology of the activity.get api is to load all activities that meet the passed in criteria and
      then go through them one by one running a series of queries on each one to determine if the contact has
      permission to see them and if not then filtering them from the array. At some point this did work with
      getcount but it had a crippling performance impact. More recently getcount was simply giving a fatal error
      when acls were in play and right before this patch the status was that no permissions
      were applied when the action is getcount.
      
      This alters that to partially apply permissions - notably a filter is added to the query that reflects
      which activity types the contact may access - this is basically those with no component or a component
      the contact has high level permissions to. It is a check that is applied in the 'allow' function
      and it still will be after this but it's a fairly cheap check and it will always return TRUE
      from here on as no activities will be fetched if their activity type is not available.
      
      The mechanism is that the CRM_Utils_SQL_Select class calls the relevant addSelectWhereClause but ONLY when
      check_permissions is TRUE. In this case the activity type filter is added if they don't have
      permission to check all activities.
      
      Tangental changes
      1) test enabled for getcount with activity type checks
      2) I added a type casting for activity_type_id in the function that retrieves
      and caches them - it should be pretty impossible for them not to be all integers
      but as I later concat them this seems a good security insurance
      3) I changed a very recently added function used in this from public to protected. It was added in Dec 2018
      and is only called from the Activity BAO and I want to discourage other classes from calling it
      now that I believe this is the correct approach.
      ff2a3553
  22. 31 Dec, 2018 1 commit
    • eileen's avatar
      Simplify handling for case checking. · 11b18d9d
      eileen authored
      We already check if the contact has generic case permissions in the component checking section.
      
      We can remove that check from the case check & also early return from there since a NO
      at that point can't be overriden
      11b18d9d
  23. 30 Dec, 2018 1 commit
    • eileen's avatar
      [REF] simplify CRM_Activity_BAO_Activity function by using early returns. · f3b59360
      eileen authored
      This function returns a bool. In the process it sets the  variable, however, once set to false in two places
      it can never be set to true, so I am simply replacing a big if block with an early return to simplify the code.
      
      This is a further block that can go but it is a slightly different patter & would remove 2 levels of 'if'
      so it feels like an easier review if I leave that out of scope
      f3b59360
  24. 27 Dec, 2018 2 commits
  25. 21 Dec, 2018 1 commit
  26. 20 Dec, 2018 1 commit