Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-11-19T04:54:20Zhttps://lab.civicrm.org/dev/core/-/issues/2197afform_html - Include Monaco dependencies2020-11-19T04:54:20Ztottenafform_html - Include Monaco dependenciesOverview
----------------------------------------
The extension `afform_html` has a dependency on Monaco, but it's not included by default with either (a) tarballs or (b) civibuild sites.
Reproduction steps
----------------------------...Overview
----------------------------------------
The extension `afform_html` has a dependency on Monaco, but it's not included by default with either (a) tarballs or (b) civibuild sites.
Reproduction steps
----------------------------------------
1. Enable core extension `afform_html`
2. View system status
Current behaviour
----------------------------------------
See a warning that the `node_modules` are missing.
Expected behaviour
----------------------------------------
Don't show a warning. Instead, the Monaco JS should be available by default.5.33.0https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/13Can we make the "Registration Info" profile be adequate for membership contri...2020-11-24T15:15:11ZHeneryHCan we make the "Registration Info" profile be adequate for membership contribution pages?I added a "Your Registration Info" profile to my new member signup contribution page but it still complains that I need to also include the Supporter Profile too.
Seems redundant but maybe it just has to be.
![supporter_profile](/uploa...I added a "Your Registration Info" profile to my new member signup contribution page but it still complains that I need to also include the Supporter Profile too.
Seems redundant but maybe it just has to be.
![supporter_profile](/uploads/baa07dc3c381876414e8a6e8f9a634ac/supporter_profile.png)https://lab.civicrm.org/dev/core/-/issues/2196E_NOTICE when creating custom field of type select2020-11-19T17:43:40ZDaveDE_NOTICE when creating custom field of type select
1. Create a custom field of type alphanumeric and drop-down select list.
1. Doesn't matter what the options are.
1. Click save.
1. `Notice: Undefined index: serialize in CRM_Custom_Form_Field->postProcess() (line 848 of .../CRM/Custom/F...
1. Create a custom field of type alphanumeric and drop-down select list.
1. Doesn't matter what the options are.
1. Click save.
1. `Notice: Undefined index: serialize in CRM_Custom_Form_Field->postProcess() (line 848 of .../CRM/Custom/Form/Field.php).`
If you have popups turned on you'll need to turn them off to see it, or look in drupal watchdog.
Seems to have been happening since at least 5.28.5.33.0https://lab.civicrm.org/dev/core/-/issues/2194Email sent to primary email if non primary email field is included on the reg...2021-10-07T21:42:51ZjitendraEmail sent to primary email if non primary email field is included on the registration pageTo replicate
- Create a profile with Fname, Lname, Email (non primary loc type).
- Use this on an event registration page.
- Now, if a user registers on this event and enters a value in the email field, the invoice is sent to the primar...To replicate
- Create a profile with Fname, Lname, Email (non primary loc type).
- Use this on an event registration page.
- Now, if a user registers on this event and enters a value in the email field, the invoice is sent to the primary email stored in civicrm. Not on the email which was entered while registering.
**Step 1**
![image](/uploads/b15adeab947da8b7435317eac4c2ce86/image.png)
**Step 2**
Thankyou page confirms that the email was sent to the primary address.
![Screenshot_2020-11-17_at_3.56.44_PM](/uploads/4d242f534eac5d118128312b927620e4/Screenshot_2020-11-17_at_3.56.44_PM.jpg)5.43.0https://lab.civicrm.org/dev/wordpress/-/issues/82Cannot create a WordPress account from the Contact record2021-10-16T08:08:01ZbgmCannot create a WordPress account from the Contact recordTo reproduce:
* As a WP admin, create a new contact record that has an email
* Click on the Actions menu
Expected: an option to create a new CMS account for this contact.
References:
* https://civicrm.stackexchange.com/questions/9092...To reproduce:
* As a WP admin, create a new contact record that has an email
* Click on the Actions menu
Expected: an option to create a new CMS account for this contact.
References:
* https://civicrm.stackexchange.com/questions/9092/wordpress-creating-new-wp-users-from-civi-contacts5.37.0https://lab.civicrm.org/dev/core/-/issues/2193Unresolved MariaDB bug breaks multi-language mode (Was: Can't create custom f...2023-10-20T05:03:17Zkirk-jacksonUnresolved MariaDB bug breaks multi-language mode (Was: Can't create custom fields in multi-language mode)Overview
----------------------------------------
**An unresolved bug in MariaDB leads to fatal database errors when multiple languages are enabled in CiviCRM.**
In CiviCRM's multi-language mode, text fields that are exposed to the UI a...Overview
----------------------------------------
**An unresolved bug in MariaDB leads to fatal database errors when multiple languages are enabled in CiviCRM.**
In CiviCRM's multi-language mode, text fields that are exposed to the UI are internationalised: The database tables containing these fields are restructured, replacing each internationalised field with multiple fields - one for each locale. However, throughout CiviCRM core and extensions there are many places where PHP code creates a record in one of these tables, but only supplies values for a single locale.
CiviCRM uses database triggers to deal with this issue: When a new record is about to be inserted into an internationalised table, a trigger is supposed to copy the values supplied for _one_ locale to all _other_ locales for which values _haven't_ been supplied.
However, a problem arises when the internationalised text fields are NOT NULL and have no DEFAULT. What the database _should_ do is run the trigger _before_ checking the NOT NULL constraints. However, due to an unresolved bug in MariaDB, it checks the NOT NULL constraints before it runs the trigger. This means that the NOT NULL constraints fail, and when the database connection's [SQL mode](https://mariadb.com/kb/en/sql-mode/) is strict, this causes a fatal database error.
If you remove strict options (`STRICT_ALL_TABLES` and `STRICT_TRANS_TABLES`) from the database connection's SQL mode, then `INSERT` generates a warning rather than an error, so CiviCRM does not crash. **But** any NOT NULL string fields get set to empty strings, which means that the trigger doesn't do its job, and may instead overwrite correct values with empty strings.
This can be seen when you try to create a custom field set in multi-language mode. Custom field sets are stored in the table `civicrm_custom_group`. The `title` field is required and is part of a UNIQUE KEY, so it is rightly constrained to be NOT NULL. But the PHP that creates a custom field set only supplies one value for title - the one for the default/current locale. The `civicrm_custom_group_before_insert` trigger is _supposed_ to copy that value to the other locales, but MariaDB doesn't run that trigger before checking the NOT NULL constraints. The results are described [below](#current-behaviour).
This MariaDB bug has resurfaced several times over the last few years. It was reported as [MDEV-10002](https://jira.mariadb.org/browse/MDEV-10002) (supposedly fixed in 10.1.10) and [MDEV-11698](https://jira.mariadb.org/browse/MDEV-11698) (supposedly fixed in 10.1.21 and 10.2.4), and now it's back as [MDEV-19761](https://jira.mariadb.org/browse/MDEV-19761), and remains unresolved.
Reproduction steps
----------------------------------------
1. In the admin menu, go to **Administer -> Localization -> Languages, Currency, Locations**.
2. Under Multiple Languages Support, tick **Enable Multiple Languages**.
3. Click **Save**.
4. From the Add Languages dropdown, select a second language.
5. Click **Save**.
6. In the admin menu, go to **Administer -> Customize Data and Screens -> Custom Fields**.
7. Click **Add Set of Custom Fields**.
8. Fill in the required fields.
9. Click **Save**.
Current behaviour
----------------------------------------
The result depends on whether the SQL mode of CiviCRM's database connection is strict or not.
With a strict SQL mode (the default since MariaDB 10.2.4) you see a fatal error message in the UI - "DB Error: unknown error" - and a fatal error message in the log file:
> INSERT INTO `civicrm_custom_group_en_GB` (`name` , `title` , `extends` , `extends_entity_column_id` , `extends_entity_column_value` , `style` , `collapse_display` , `help_pre` , `help_post` , `weight` , `is_active` , `is_multiple` , `max_multiple` , `collapse_adv_display` , `created_id` , `created_date` , `is_public` , `icon` ) VALUES ('Event_Feedback' , 'Event Feedback' , 'Activity' , NULL , '28' , 'Inline' , 0 , '' , '' , 6 , 1 , 0 , NULL , 0 , 202 , 20201116132750 , 1 , '' ) [nativecode=1423 ** Field of view 'civicrm.civicrm_custom_group_en_GB' underlying table doesn't have a default value]
With a non-strict SQL mode, CiviCRM doesn't crash, and it does create a new custom field set, but its title is an empty string.
Expected behaviour
----------------------------------------
A new custom field set should be created with the specified title, and you should be taken to the form for creating the first custom field in that set.
Environment information
----------------------------------------
* **CiviCRM:** _5.28.4, 5.33.alpha1_
* **CMS:** Backdrop, Drupal 7, Drupal 8, Drupal 9, WordPress 5.5
* **Database:** _MariaDB 10.3.25_
This bug can be reproduced on most of [the official CiviCRM demo sites](https://civicrm.org/demo#sandboxes), including [Backdrop](https://bmaster.demo.civicrm.org/), [Drupal 7](https://dmaster.demo.civicrm.org/), [Drupal 8](https://d8-master.demo.civicrm.org/), [Drupal 9](https://d9-master.demo.civicrm.org/) and [WordPress](http://wpmaster.demo.civicrm.org/).
Comments
----------------------------------------
CiviCRM's implementation of internationalisation is dependent on database triggers at a deep level, and as such it is dependent on the MariaDB bug being fixed. It's difficult to see how this dependence could be removed without a significant rewrite of core code.
There are many places in CiviCRM core code where new DAO objects are created without regard to internationalisation, not to mention in the API and in third-party extensions. It is practically infeasible to modify all of that code, and therefore any solution needs to work for code that is I18n-agnostic.
I can think of three possible approaches:
1. **Temporarily disable strict SQL mode:** Strict options could be removed from the SQL mode immediately before `CRM_Core_DAO` passes an `INSERT` to `DB_DataObject`, and then reinstated immediately afterwards. This is a nasty hack; not recommended, as it could suppress genuine database errors. Also, the triggers defined in `CRM_Core_I18n_Schema::triggerInfo` would have to be rewritten so that they didn't copy empty strings to other locales.
2. **Rewrite SQL before executing:** The `CRM_Core_I18n_Schema::rewriteQuery` function localises SQL statements by replacing the names of internationalised tables (e.g. `civicrm_custom_group`) with the names of locale-specific views onto those tables (e.g. `civicrm_custom_group_en_GB`). This function could instead be used to perform a much more extensive rewrite of the SQL statements so that INSERTs and UPDATEs would operate directly on the internationalised tables, and supply default values for _all_ locales. This would make the database triggers redundant, removing CiviCRM's dependence on them. However, it would require some heavy lifting with an SQL parser (recommended) or a nightmare of regular expressions (not recommended).
3. **Fix the underlying MariaDB bug:** [The current incarnation of this bug](https://jira.mariadb.org/browse/MDEV-19761) was reported over a year ago, and it still hasn't been fixed. A fix needs to be [written and submitted](https://mariadb.com/kb/en/community/) as a PR, which needs to be accepted and merged by the MariaDB maintainers. This would give the best outcome long-term, but could take a long time.https://lab.civicrm.org/dev/core/-/issues/2192Social Media Share footer doesn't display on Contribution pages when requested2020-11-17T21:44:02ZnicolSocial Media Share footer doesn't display on Contribution pages when requestedWhile testing https://github.com/civicrm/civicrm-core/pull/18880 I noticed that selecting "Add footer region with Twitter, Facebook and LinkedIn share buttons and scripts?" in the config screen for contribution pages showed the social sh...While testing https://github.com/civicrm/civicrm-core/pull/18880 I noticed that selecting "Add footer region with Twitter, Facebook and LinkedIn share buttons and scripts?" in the config screen for contribution pages showed the social share footer on event pages but not contribution pages for Joomla.
A bit more testing and I found the same behaviour on D7, D8, Backdrop and Wordpress, which you can see on the sandbox sites (for e.g. https://wpmaster.demo.civicrm.org/contribution-page/ & https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=1 don't include the footer, even tho it is selected in the admin interface).
Either the footer isn't supposed to display, and the Contribution Page config page should remove "Add footer region with Twitter, Facebook and LinkedIn share buttons and scripts?" check box – or there's an issue with the display of the social footer.
![image](/uploads/5125898387ae48212539ee2414e44b9c/image.png)https://lab.civicrm.org/dev/core/-/issues/2191CiviCRM 5.31 post upgrade errors, You have requested a non-existent service "...2020-12-11T02:13:06Zjustinfreeman (Agileware)CiviCRM 5.31 post upgrade errors, You have requested a non-existent service "mosaico_graphics"; You have requested a non-existent service "civi_flexmailer_required_tokens"; Unrecognized value for setting 'flexmailer_traditional'.Just a FYI that we are seeing this CiviCRM 5.31 post upgrade errors, You have requested a non-existent service "mosaico_graphics" and You have requested a non-existent service "civi_flexmailer_required_tokens". Also see the following err...Just a FYI that we are seeing this CiviCRM 5.31 post upgrade errors, You have requested a non-existent service "mosaico_graphics" and You have requested a non-existent service "civi_flexmailer_required_tokens". Also see the following error message: Unrecognized value for setting 'flexmailer_traditional'.
![Screenshot_20201126_105000](/uploads/7b78860515b992cfc898fc7bcfab7e82/Screenshot_20201126_105000.png)
![Screenshot_20201126_104951](/uploads/9addf493d0c9fc3c8b2e649e50b2c81e/Screenshot_20201126_104951.png)
Causes final step of the upgrade process to result in an error:
There has been a critical error on your website. Please check your site admin email inbox for instructions.
Learn more about debugging in WordPress.
And then this error message is displayed intermittently whilst navigating CiviCRM pages.
Error is output as response to all AJAX requests as the JSON payload, HTML error response which breaks that functionality.
Solution is to:
1. Visit the Administer CiviCRM, Flexmailer Settings and re-save the Flexmailer Settings.
2. Visit the Administer CiviCRM, Mosaico Settings page and saving
2. Clear the CiviCRM caches
Then CiviCRM pages should load normally.
Environment:
CiviCRM 5.31
WordPress 5.5.3
Agileware Ref: CIVICRM-1604 and CIVICRM-16125.32.2https://lab.civicrm.org/dev/core/-/issues/2190E_NOTICE when calling CRM_Core_BAO_SchemaHandler::createTable with logging tu...2020-11-17T21:07:10ZDaveDE_NOTICE when calling CRM_Core_BAO_SchemaHandler::createTable with logging turned on[These two lines](https://github.com/civicrm/civicrm-core/blob/d1eed91c218f4c285a535275e36732f68463824b/CRM/Logging/Schema.php#L818-L819) generate an E_NOTICE because `logTableSpec[$table]` doesn't exist yet.
A bigger question is wouldn...[These two lines](https://github.com/civicrm/civicrm-core/blob/d1eed91c218f4c285a535275e36732f68463824b/CRM/Logging/Schema.php#L818-L819) generate an E_NOTICE because `logTableSpec[$table]` doesn't exist yet.
A bigger question is wouldn't that always be missing since the table hasn't been created yet, so what's the point in even checking the existing value at all?
And why have the lines above that loop thru all the engines but then don't do anything with the resulting list? It looks like maybe it's just left over from when the engine was changed from ARCHIVE to INNODB.
PR coming - just deciding how deep I want to get into this.5.33.0https://lab.civicrm.org/dev/drupal/-/issues/146Wrong link to Drupal's permissions page2020-11-19T19:27:11ZfkohrtWrong link to Drupal's permissions pageCiviCRM 5.31 on Drupal 8 has in the web UI at `/civicrm/admin/access?reset=1` a link called _Drupal8 Access Control_, but it is leading to `/civicrm/admin/access?reset=1` instead of `/admin/people/permissions`, i.e. not where it should.CiviCRM 5.31 on Drupal 8 has in the web UI at `/civicrm/admin/access?reset=1` a link called _Drupal8 Access Control_, but it is leading to `/civicrm/admin/access?reset=1` instead of `/admin/people/permissions`, i.e. not where it should.5.33.0https://lab.civicrm.org/dev/core/-/issues/2189Activity Type cleanup2023-06-15T05:03:16ZJonGoldActivity Type cleanupCurrently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed...Currently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed Invoice" for CiviContribute) don't have a `component_id` assigned.
It also seems that "Meeting" and "Phone Call" are set as `is_reserved`, but there aren't any references to those in the codebase such that disabling or deleting them should affect a Civi install.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2188Custom fields of type "Integer" with radio buttons can cause Advanced Search ...2021-01-07T03:26:26ZJonGoldCustom fields of type "Integer" with radio buttons can cause Advanced Search to break#### Steps to replicate
* Create a new custom field (via the UI) of type Integer, HTML Type of radio buttons.
* Set "Is Searchable" to "yes" and save.
* Visit Advanced Search.
#### Expected result
Advanced Search worked identically to b...#### Steps to replicate
* Create a new custom field (via the UI) of type Integer, HTML Type of radio buttons.
* Set "Is Searchable" to "yes" and save.
* Visit Advanced Search.
#### Expected result
Advanced Search worked identically to before the field was added.
#### Actual result
A JavaScript error:
```
Uncaught query function not defined for Select2 custom_9_from
```
The JS error will cause various parts of the form to stop working; the exact effect depends on the load order of the field in question. Select2 may stop working, accordions that load template snippets via AJAX may fail to open.
#### Technical Notes
The "Add Custom Field" form has a default for "Search by Range" set to "Yes", which is hidden by JS until someone sets "Is Searchable" to "Yes".
However, there's no widget to search by range on a multiple-choice field (it doesn't really make sense) so "Search by Range" remains hidden. Unfortunately, that means the field takes the default of "Yes". Advanced Search breaks because the widget doesn't exist.
This issue exists in master, but has existed at least as far back as 5.13.5.33.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2187Allow for the default number of search results to be configurable2021-09-07T10:20:35ZseamusleeAllow for the default number of search results to be configurableOverview
----------------------------------------
At the present moment the default number of results to be returned on a search is hard coded to 50 in `CRM/Utils/Pager.php` this should ideally be configurable using settings
Example use...Overview
----------------------------------------
At the present moment the default number of results to be returned on a search is hard coded to 50 in `CRM/Utils/Pager.php` this should ideally be configurable using settings
Example use-case
----------------------------------------
A site wants to show 100 contacts / memberships / grants etc on a screen at a time rather than 50
Current behaviour
----------------------------------------
Hard coded default value of 50
Proposed behaviour
----------------------------------------
Create a setting to handle the default value and set it on various search forms.5.39.0https://lab.civicrm.org/dev/wordpress/-/issues/80Users cannot be created if no unsupervised deduping rule exists2021-10-20T09:51:13ZBradley TaylorUsers cannot be created if no unsupervised deduping rule existsWe have recently had an issue where users could not be added via the WordPress admin add new user screen. The following exception was logged: `Unsupervised rule for Individual does not exist`
**Steps to reproduce:**
- Go to the CiviCRM ...We have recently had an issue where users could not be added via the WordPress admin add new user screen. The following exception was logged: `Unsupervised rule for Individual does not exist`
**Steps to reproduce:**
- Go to the CiviCRM dedup rules config screen (/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fcontact%2Fdeduperules&reset=1)
- For any unsupervised rules under the "Individual Rules" table, either delete the rule, or change the usage type to "General".
- Try adding a new WordPress user at /wp-admin/user-new.php
I've not tested this, but I expect the easiest course of action is to wrap the call to `synchronizeUFMatch` in `CiviCRM_For_WordPress_Users` in a try-catch block. I've not checked to see if this issue affects Drupal/ Joomla.
There is currently nothing in the documentation to suggest having an unsupervised rule is a requirement, but if not having an unsupervised rule will cause other problems then this should be clearly stated in https://docs.civicrm.org/user/en/latest/common-workflows/deduping-and-merging/https://lab.civicrm.org/dev/core/-/issues/2186Support For multiple cases while creating email activity2020-11-26T15:35:37Zshahrukh_compucorpSupport For multiple cases while creating email activityOverview
----------------------------------------
CiviCRM has functionality to allow you to create email activities and to optionally attach it to one case as well.
Currently the email activity creation form only accepts one case id un...Overview
----------------------------------------
CiviCRM has functionality to allow you to create email activities and to optionally attach it to one case as well.
Currently the email activity creation form only accepts one case id unlike contact id parameter which can accept multiple comma separated ids.
This makes it impossible to attach the same email activity to multiple cases.
Note: I am not sure if there is any particular reason that this form does not support multiple cases as the print merge document does support multiple case ids.
Problem statement
----------------------------------------
Currently it is impossible to attach one email activity to multiple cases.
Example use-case
----------------------------------------
1. Go to email activity creation form with valid contact ids in parameter and multiple valid case ids separated by comma.
2. Fill the form and Proceed to submit.
Current behaviour
----------------------------------------
The submitted form results in an error.
Proposed behaviour
----------------------------------------
The caseid parameter can be renamed to caseids so that it can accept multiple case ids separated by comma similar to cid parameter and the created activity can be attached with all the providid cases.https://lab.civicrm.org/dev/core/-/issues/2185Exceptions - lets do what we said we would do2023-06-25T05:03:22ZeileenExceptions - lets do what we said we would doAnd I quote https://github.com/civicrm/civicrm-core/blob/fdf73b0db343733c70bf217ffd121d4cb3f03480/CRM/Core/TemporaryErrorScope.php
This is an evil, evil work-around for CRM-11043. It is used to
* temporarily change the error-handling b...And I quote https://github.com/civicrm/civicrm-core/blob/fdf73b0db343733c70bf217ffd121d4cb3f03480/CRM/Core/TemporaryErrorScope.php
This is an evil, evil work-around for CRM-11043. It is used to
* temporarily change the error-handling behavior and then automatically
* restore it -- that protocol is an improvement over the current protocol
* (in which random bits of code will change the global error handler
* setting and then forget to change it back). This class and all
* references to it should be removed in 4.3/4.4 (when we adopt
* exception-based error handling).https://lab.civicrm.org/dev/core/-/issues/2184OAUTH2 google doesn't seem to give you refresh tokens easily2023-06-15T01:11:27ZDaveDOAUTH2 google doesn't seem to give you refresh tokens easilyIf you run the authorization_code flow to obtain an access token from google I find the response often doesn't contain a refresh token, so then it can't really be used for cron jobs.
There was some suggestion that you have to delete the...If you run the authorization_code flow to obtain an access token from google I find the response often doesn't contain a refresh token, so then it can't really be used for cron jobs.
There was some suggestion that you have to delete the token in the civi admin AND at google. This [issue](https://github.com/googleapis/google-api-python-client/issues/213#issuecomment-612412147) suggests it only gives a refresh token when you are prompted for consent and not subsequent times (or if you pass the prompt=consent parameter).
It may only come up as a problem during a testing cycle where you keep failing and re-requesting, and for people who are setting up an account and get it right the first time it won't be a problem.
TBD5.64.0https://lab.civicrm.org/dev/core/-/issues/2183OAuth2 Admin - Add generic UI for clientCredential+userPassword grants2023-05-27T05:03:18ZtottenOAuth2 Admin - Add generic UI for clientCredential+userPassword grantsOverview
----------------------------------------
When [configuring an OAuth2 client](https://docs.civicrm.org/sysadmin/en/latest/setup/oauth/), one first registers the `client_id`/`client_secret` and then grants access to specific reso...Overview
----------------------------------------
When [configuring an OAuth2 client](https://docs.civicrm.org/sysadmin/en/latest/setup/oauth/), one first registers the `client_id`/`client_secret` and then grants access to specific resources.
The grant behavior may be integrated into other parts of the UI (as with "Add Mail Accounts"), but - for simple integrations - it may be less work to [use the generic grant button](https://docs.civicrm.org/sysadmin/en/latest/setup/oauth/#authorize-access-to-resources).
Current behavior
----------------------------------------
There is one button for initiating the `OAuthClient`.`authorizationCode` flow.
![](https://lab.civicrm.org/documentation/docs/sysadmin/-/raw/master/docs/img/OAuthDemo-1.png)
This is probably the single-most important OAuth grant flow, but it is not the only one.
Proposed behavior
----------------------------------------
Provide options for three common grant flows:
* `OAuthClient`.`authorizationCode`
* `OAuthClient`.`userPassword`
* `OAuthClient`.`clientCredentials`
These APIs are implemented - but we need some form updates to use them.https://lab.civicrm.org/dev/core/-/issues/2182"Edit Mail Account" - Hide "Password" field on OAuth-based accounts2023-05-28T05:03:20Ztotten"Edit Mail Account" - Hide "Password" field on OAuth-based accountsOverview
----------------------------------------
Unnecessary field is likely to cause confusion.
Reproduction steps
----------------------------------------
1. [Create an OAuth-based email account](https://docs.civicrm.org/sysadmin/en...Overview
----------------------------------------
Unnecessary field is likely to cause confusion.
Reproduction steps
----------------------------------------
1. [Create an OAuth-based email account](https://docs.civicrm.org/sysadmin/en/latest/setup/oauth/#register)
1. After creating the account, you see the "Edit Mail Account screen:
![](https://lab.civicrm.org/documentation/docs/sysadmin/-/raw/master/docs/img/AddMailAccount-Details.png)
Current behavior
----------------------------------------
The field "Password" is displayed. However, it is completely ignored. The existence of an OAuth2 token means that it is never used.
Expected behavior
----------------------------------------
Don't show the field.
Orgive some kind of indicator that there's an active token which renders the field irrelevant.
Maybe add a link to `civicrm/admin/oauth` where one can view/inspect the tokens.https://lab.civicrm.org/dev/core/-/issues/2181Add support for storing per-user OAuth2 tokens2023-08-13T05:03:28ZtottenAdd support for storing per-user OAuth2 tokensOverview
----------------------------------------
Expand API support for OAuth2 tokens to support transactional/interactive/short-term use-cases.
See https://docs.civicrm.org/dev/en/latest/framework/oauth/#model-token for more discussio...Overview
----------------------------------------
Expand API support for OAuth2 tokens to support transactional/interactive/short-term use-cases.
See https://docs.civicrm.org/dev/en/latest/framework/oauth/#model-token for more discussion of per-system tokens vs per-user tokens.
Example use-case
----------------------------------------
1. Click on **Import Contacts**.
1. For a source, choose **Google Drive**
1. Run OAuth2 "Authorization Code" flow to get an access token. Store the access-token just for this user.
1. Proceed to use the token for choosing+reading a spreadsheet.
Current behavior
----------------------------------------
When running the "Authorization Code" flow, the only available storage option is `OAuthSysToken`:
```php
$start = civicrm_api4('OAuthClient', 'authorizationCode', [
'where' => [['id', '=', 123]],
'storage' => 'OAuthSysToken',
])->single();
```
This storage is appropriate for long-term system-level services like CiviMail bounce checking - but not for transactional/interactive usage. Ex:
* Suppose you implement the Google Drive spreadsheet example using `OAuthSysToken`.
* Suppose you want to allow Alice and Bob to both import from Google Drive. Thus, both can read/write `OAuthSysToken` records.
* Alice imports one spreadsheet, so it creates an `OAuthSysToken`
* Bob imports one spreadsheet, so it creates an `OAuthSysToken`
* Alice can see Bob's token just as well as her own; and vice-versa. This allows them to go poking at each other's data.
Proposed behavior
----------------------------------------
Add an API `OAuthUserToken` which works like `OAuthSysToken`
```php
$start = civicrm_api4('OAuthClient', 'authorizationCode', [
'where' => [['id', '=', 123]],
'storage' => 'OAuthUserToken',
])->single();
```
*Except* that it defines clearer ownership (associating the token with the current user) and expiration mechanism (so that we don't hold on to it forever).
Some possible implementations:
* `OAuthUserToken extends BasicEntity`. Use data-storage in `$_SESSION` or `Civi::cache('session')`. This makes it invisible to other users, and it provides an end-of-life plan for the token.
* `OAuthUserToken extends DAOEntity`. Use data-storage in MySQL (and mandatory filters/cleanups to deal with ownership and expiration).