The token processor code was updated to handle the label syntax in
https://github.com/civicrm/civicrm-core/pull/21570 with tests added.
The greeting processing still doesn't go through the token processor.
I'm trying to fix that but that change has a few moving parts so
chasing out our last reference to contact.prefix_id in this PR
and also doing the DB updates to switch over to use the preferred
tokens and make them work with
replaceGreetingTokens (albeit hopefully in the
short-ish term we will stop using that function)

CIVICRM-1844 Remove all references to safe_mode, DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0

Deprecates the CRM_Core_BAO_Note::del() function and refactors out all references to it.
Related to work on #2757

Remove e-notice issue found by dave d

Before: CustomGroup ACLs made no distinction between VIEW and EDIT

After: User with VIEW can see a custom group but not edit it, both in the UI and the API.

Note this includes the order api ensuring that the contribution_recur_id is passed through to
any created memberships

Follow up to https://github.com/civicrm/civicrm-core/pull/20792
- although that can be closed if this is merged

Remove participant payment create from order api

This is now done in the line item create & we went through to 'prove' that it works with
extra validation

temp

Api supports a key 'option_values' by always setting the 'magic' param
option_type to 1. v4 doesn't - but creating option values when creating
a custom field is desirable. This fixes so that the form still
'opts out' if it passes in '2' but otherwise we create the option values
if passed in.

Just a teensy bit less magic in the api layer & bao

This moves code to calculate membership dates for new memberships from the
v3 api Membership.create and the batch entry membership form to the membership bao.

I think more cleanup could follow this - in the api most obviously and
the BAO is a bit insane still

This has test cover in the v3 api membership test and in
CRM_Batch_Form_EntryTest

Usually it's safe to assume the `id_field` === "id", which is automatically returned
by APIv3. However in the case of looking up records by name, etc. we must ensure that value
gets returned.

This changes the order api so that it is not necessary to figure out the details
of the default price set when using it to create memberships.

Contribution mode was only set to be used to set isRelatedID
here https://github.com/civicrm/civicrm-core/pull/20653/files#diff-4c9d0b1abe07057a4eea2b47bc627eecb95face8ed8d86c1c005312a52cca811L3420

but we removed that....

[REF] Shift special handling of extends param of the customGroup create into apiv3 and change Custom Group form to use apiv3

An unreleased change adds the entity ids for membership to the return values.

However, on digging into further cleanup I realised that the entity ids are in
the line item array, along with other values which may or may not be useful,
and it's cleaner, more complete and more maintainable to return the line_items.

It requires an extra foreach loop in the calling code but
I don't see that as a downside.

We should change this in the rc so what is released is consistent

Test cover in testSubmitRecur & other tests in CRM_Member_Form_MembershipTest

Before: in_array($foo, array_keys($bar))
After: array_key_exists($foo, $bar)

Context: AuthorizeEvent did not allow tracking userID.  AuthorizeRecordEvent
is spec'd to track userID.  This is a step toward supporting checks when the
target user is non-present (ie not the user in the browser/session).
However, this step is not *sufficient* - additional work is also needed to
support non-present users.

Original: AuthorizeEvent and AbstractAction::isAuthorized did not report
current userID.  However, the wiring for AuthorizeRecordEvent is spec'd
to allow userID.

Previous: Made a breaking change in the signature of
AuthorizeEvent/AbstractAction::isAuthorized() to report userID.  However,
even with the break, it's not clear if this is the best approach.

Revised:
* Both AuthorizeEvent and AuthorizeRecordEvent report `userID`. This allows consumers to start using
  this information -- laying the groundwork for future changes.
* If an existing event-consumer ignores the `userID`, it will still work as correctly as before. This is
  because we guarantee that the userID matches the session-user.
* The signature of `AbstractAction::isAuthorized()` matches its original. No BC break. However, the method
  is flagged `@internal` to warn about the prospect of future changes.
* In the future, after we do more legwork on to ensure that the overall
  system makes sense, we may flip this and start doing non-present users.

Code paths:

* Before: There are many callers to `$bao::checkAccess()`.
* After: There is only one caller to `$bao::checkAccess()` (ie `CoreUtil`).

Delegation mechanics:

* Before: When delegating access-control to another entity, various things invoke  `$bao::checkAccess()`.
* After: When delegating access-control to another entity, various things invoke `CoreUtil::checkAccessDelegated()`

eileen authored 4 years ago and totten committed 3 years ago

This adds a static ::checkAccess function to all BAOs, which dispatches to
a protected _checkAccess function in that BAO, as well as a new hook:
hook_civicrm_checkAccess($entity, $action, $record, $contactID, &$granted)

[php8-compat] Fix issue in APIv3 Where by because product has a column called options the testCreateSingleValueAlter triggers a cannot access offset of type string on string in php8