Resolve #119 by prefixing the entity names with CiviRules

Merge branch 'issue_119' into 'master'

Resolve #119 by prefixing the entity names with CiviRules

Closes #119

See merge request extensions/civirules!119

Update CHANGELOG.md

Update CHANGELOG.md

Update CHANGELOG.md

Update info.xml

Update CHANGELOG.md

Update CHANGELOG.md

Update info.xml

Fix problems with HasTag Condition and Add/Remove Tag Actions

Merge branch 'master' into 'master'

Fix problems with HasTag Condition and Add/Remove Tag Actions

See merge request extensions/civirules!120

Update CHANGELOG.md

Update CHANGELOG.md

Fix HasTag Condition and Tag Added/Removed Actions for the Contact Tagged/Untagged Triggers

Define getEntity() on TriggerData base class

Merge branch 'getEntity' into 'master'

Define getEntity() on TriggerData base class

Closes #121

See merge request extensions/civirules!122

Update CHANGELOG.md

Merge branch 'ContactTaggedTrigger' into 'master'

Fix HasTag Condition and Tag Added/Removed Actions for the Contact Tagged/Untagged Triggers

See merge request extensions/civirules!123

Update CHANGELOG.md

Attempt to stash TriggerData primary entity type in setEntityData()

(REF) Testing - Extract class-file "TAP7"

Testing - Port TAP printer to PHPUnit 9

tools/scripts/phpunit - Enable tap for phpunit9

Merge pull request #25956 from totten/master-tap

(dev/core#4188) PHPUnit - Port TAP printer to v9.x

Overview

TAP is a format for listing test results. It's handy for displaying large test-jobs -- because you can monitor progress and see when errors arise. We've been using it for sometime. But it requires a phpunit plugin.

ping @seamuslee001

https://lab.civicrm.org/dev/core/-/issues/4188

Before

You can use Civi\Test\TAP with phpunit8 (and some older ones):

CIVICRM_UF=UnitTests phpunit8 --printer '\Civi\Test\TAP' tests/phpunit/CRM/Utils/StringTest.php

After

You can additionally use Civi\Test\TAP with phpunit9:

CIVICRM_UF=UnitTests phpunit9 --printer '\Civi\Test\TAP' tests/phpunit/CRM/Utils/StringTest.php

Also, the file-layout for ./Civi/Test/TAP*.php is a bit more consistent. (Every implementation of TAP has a full file of its own.)

seems fine to me

Also there is this extension here https://civicrm.org/extensions/gender-self-identify that can help but I agree with @homotechsual on the defaults for CiviCRM

Upgrade fix for url change

Merge pull request #25962 from eileenmcnaughton/import_url

Upgrade fix for url change

Overview

We standardised the contribution import url to match the others - but I didn't add the upgrade fix

@colemanw

Jenkins re test this please

dev/core#4029 Ensure that Pan Truncation and card type id is recorded when processing front end contributions

dev/core#4029 Ensure that Pan Truncation and card type id is recorded when processing front end contributions

… when processing front end contributions

Overview

This fixes an issue where on front end Contribution form the Card Type ID and Pan Truncation were not being stored since about 5.49

Before

Card details not stored

After

Card details are stored

Technical Details

This seemed to be assuming that the original params would be returned with the payment processor result added in but that I think has changed and is not consistent with https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/Form/Registration/Confirm.php#L921 and https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution.php#L1185

ping @Stoob @eileenmcnaughton

I'm flagging this as merge ready as I'm treating myself as the reviewer here and also the code produced matches Tim's original draft of what he thought it should look like as per the comments on the previous PR, I'll give Tim a few more days if he wants to comment further but I understand the code and it seems fine to me

dev/core#3133 - Extend Authx functionality to support validation of externally generated JWTs

Migrate legacy rest to appropriate place

Remove legacy auth as not needed due to it self registering now

Overview

https://lab.civicrm.org/dev/core/-/issues/3133

Before

Authx,when processing a Bearer token, expects the scope claim to be "authx" and the sub claim to be "cid:{thecontactid}", as generated by civicrm itself.

After

Other extensions can override the handling of scope and sub claims. For example it would enable this extension to work: https://github.com/australiangreens/civiauth0jwt

Technical Details

A symphony event 'civi.authx.jwtclaimscheck' is dispatched, being a new JwtClaimsCheckEvent. An extension listening to this can read the (decoded) claims and as call rejectScope(), acceptScope(), rejectSub() and acceptSub() as required. The AuthX authenticator checks if any overrides are present and uses them instead of the default behaviour.

Comments

Very happy for feedback on improvements/changes to this. This is my first contribution to civicrm-core.

closing this in favour of the resubmission here https://github.com/civicrm/civicrm-core/pull/25952

…xternally generated JWTs

Overview

This adds support for using externally generated JWTs e.g. by Auth0 to authenticate users using Authx

Before

Authx,when processing a Bearer token, expects the scope claim to be "authx" and the sub claim to be "cid:{thecontactid}", as generated by civicrm itself.

After

Other extensions can override the handling of checking of the credential in an example such as this extesnion https://github.com/australiangreens/civiauth0jwt

Technical Details

This changes to fire a new event civi.authx.checkCredential to allow extensions to validate if an authentication credential should be accepted or not.

This is a re-submit of https://github.com/civicrm/civicrm-core/pull/23019 which some minor modifications to make it work with the current Authx code

dev/core#3133 - Extend Authx functionality to support validation of externally generated JWTs

Migrate legacy rest to appropriate place

(dev/core#4188) Update CRM tests for phpunit9 compatibility

Merge pull request #25949 from totten/master-phpunit9-crm

(dev/core#4188) Update CRM tests for phpunit9 compatibility

Overview

These tests failed on phpunit9 because upstream swapped around the semantics of assertContains().

Same issue as #25947 but applied to the phpunit-crm suite.

(dev/core#4188) Update APIv3 tests for phpunit9 compatibility

These tests failed on phpunit9 because upstream swapped out around the semantics of assertContains().

The specific issue is whether an array like ["1","2","3"] contains the value 2.

• assertContains() in phpunit8 says yes.
• assertContains() in phpunit9 says no.
• assertContainsEquals() in both phpunit8+phpunit9 says yes.

Merge pull request #25948 from totten/master-phpunit9-api3

(dev/core#4188) Update APIv3 tests for phpunit9 compatibility

Overview

Same issue as #25947, but applied to the phpunit-api3 suite. These tests failed on phpunit9 because upstream swapped around the semantics of assertContains().

The specific issue is whether an array like ["1","2","3"] contains the value 2.

Before

• assertContains() in phpunit8 says yes => tests pass.
• assertContains() in phpunit9 says no => tests fail.

After

• assertContainsEquals() in both phpunit8+phpunit9 says yes => tests pass.