Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-15T02:24:51Zhttps://lab.civicrm.org/dev/core/-/issues/5091crm.ajax.js uses synchronous XHR2024-03-15T02:24:51ZJonGoldcrm.ajax.js uses synchronous XHROverview
----------------------------------------
When editing a contribution loaded in a modal, if the server is configured to disallow synchronous XHR, the "Cancel" and "Save" buttons don't appear.
Example use-case
------------------...Overview
----------------------------------------
When editing a contribution loaded in a modal, if the server is configured to disallow synchronous XHR, the "Cancel" and "Save" buttons don't appear.
Example use-case
----------------------------------------
1. In your web server config, modify your Permissions-Policy or add one that disables synchronous XHR, e.g. for Apache:
```
Header always set Permissions-Policy "sync-xhr=()"
```
1. Click **Edit** next to a contribution (without opening in a new tab, so it appears in a modal).
Current behaviour
----------------------------------------
"Cancel" and "Save" buttons are missing.
Proposed behaviour
----------------------------------------
"Cancel" and "Save" buttons should appear.
Comments
----------------------------------------
The console error is:
```
[Violation] Permissions policy violation: Synchronous requests are disabled by permissions policy.
```
It faults `crm.ajax.js` line 329 (currently: `that.element.html(data.content);`).
Per the [XHR spec](https://xhr.spec.whatwg.org/#the-open()-method):
> Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user’s experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when the current global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" DOMException when it occurs.
This isn't urgent - most folks aren't blocking Synchronous XHR - but since this is the only issue I've seen in months of having this permissions policy, it seems like we can get atop things.https://lab.civicrm.org/dev/core/-/issues/5086Ability to export FormBuilder forms from the UI2024-03-18T15:35:22ZherbdoolAbility to export FormBuilder forms from the UIWe've got an export link for SearchKit, but if a saved search is wrapped up in a FormBuilder form there's no easy way to also export those files. I can imagine a modal with the text from the forms files (`*.html`, `*.json`) and a link to...We've got an export link for SearchKit, but if a saved search is wrapped up in a FormBuilder form there's no easy way to also export those files. I can imagine a modal with the text from the forms files (`*.html`, `*.json`) and a link to copy it. Or even ability to save the files as a zip file.
And I suppose we'd need an import link as well to import on a different site (similar to SearchKit's link).https://lab.civicrm.org/dev/core/-/issues/5083SearchKit: It's not possible to uppercase countries and states/provinces2024-03-12T13:30:39ZfrancescbassasSearchKit: It's not possible to uppercase countries and states/provincesReproduced on dmaster.demo.civicrm.org at 5.73.alpha1
![imatge](/uploads/92832dc535bb7b462cd714cc3b58dec5/imatge.png)Reproduced on dmaster.demo.civicrm.org at 5.73.alpha1
![imatge](/uploads/92832dc535bb7b462cd714cc3b58dec5/imatge.png)https://lab.civicrm.org/dev/core/-/issues/5076Error on install2024-03-12T13:27:18ZJonGoldError on installI just attempted to install via the normal web UI for the first time in a very long time. Brand new D7 site, brand new Civi. Disabled all components but CiviEvent and CiviMail. On install, I received this message:
```
CRM_Extension_E...I just attempted to install via the normal web UI for the first time in a very long time. Brand new D7 site, brand new Civi. Disabled all components but CiviEvent and CiviMail. On install, I received this message:
```
CRM_Extension_Exception_DependencyException: Cannot disable extension due to dependencies. Consider disabling all these: civi_campaign,civi_case,civi_contribute,civi_member,civi_pledge,civi_report,financialacls in CRM_Extension_Manager->disable() (line 387 of /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Extension/Manager.php).
```
Reloading the page got me past the error but since it's the first thing a new admin will see it's worth fixing IMO.https://lab.civicrm.org/dev/core/-/issues/5075When adding fields to a profile if you choose Contact as the entity the dropd...2024-03-12T13:26:32ZDaveDWhen adding fields to a profile if you choose Contact as the entity the dropdown includes Grant fieldsThis sounds familiar but I'm not sure if it's something new or something that came back. I can't find a ticket about it with a quick search.This sounds familiar but I'm not sure if it's something new or something that came back. I can't find a ticket about it with a quick search.https://lab.civicrm.org/dev/core/-/issues/5074Standalone installer header squished on wide screens2024-03-12T13:25:50ZufundoStandalone installer header squished on wide screensOn screens wider than 2000px the installer title overlaps the logo:
![image](/uploads/5bdae7eb821fc67c637939d2abc7f983/image.png)
Minor but it's not the best intro for new people to CiviCRM!
(Maybe it is a good intro :eyes: )On screens wider than 2000px the installer title overlaps the logo:
![image](/uploads/5bdae7eb821fc67c637939d2abc7f983/image.png)
Minor but it's not the best intro for new people to CiviCRM!
(Maybe it is a good intro :eyes: )https://lab.civicrm.org/dev/core/-/issues/5072SearchKit: Ghost custom data2024-03-12T15:46:29ZfrancescbassasSearchKit: Ghost custom dataHow to reproduce:
1. Create a custom field for a membership type.
2. Create a membership type and fill the custom field.
3. Change the membership type for the previous membership. Membership no longer have custom field, at least at UI l...How to reproduce:
1. Create a custom field for a membership type.
2. Create a membership type and fill the custom field.
3. Change the membership type for the previous membership. Membership no longer have custom field, at least at UI level, data remains in database tables.
4. Create a SearchKit to list memberships and custom field created in step 1.
5. The SearchKit results show data for non-applicable field for the membership created in step 2.
I suspect it's applicable for custom data groups associated with other entities (contact subtypes, participants, etc)https://lab.civicrm.org/dev/user-interface/-/issues/70Test & resolve final accordion markup pattern rewrite: CRMDashlet (pattern 2)2024-03-07T13:51:41ZnicolTest & resolve final accordion markup pattern rewrite: CRMDashlet (pattern 2)The accordion issue #60 has just one pattern left remaining, which appears in one part of CiviCRM, the dashboard. This is more complex than other accordions as the summary bar needs to be drag-and-drop, as well as have function buttons f...The accordion issue #60 has just one pattern left remaining, which appears in one part of CiviCRM, the dashboard. This is more complex than other accordions as the summary bar needs to be drag-and-drop, as well as have function buttons for refresh, close, and expand-to-modal.
There's a WIP PR for it here: https://github.com/civicrm/civicrm-core/pull/29613 – which has two outstanding issues:
- the expand-to-modal duplicates the title.
- the refresh js in `crmDashlet.component.js` needs to be updated
In addition, testing needs to confirm on several CMS the following still work:
- [ ] drag,
- [ ] drop,
- [ ] expand fullscreen,
- [ ] expand/collapse accordion,
- [ ] refresh,
- [ ] remove dashlet
- [ ] inactive dashlet state (when clicking 'available dashlet')Improve Civi's front-endhttps://lab.civicrm.org/dev/core/-/issues/5070Contribution pending status wrong2024-03-07T18:16:21Zaydunsaidan.saunders@squiffle.ukContribution pending status wrong## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact...## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact.
2. `Actions` \> `Add Contribution` (or `Contributions` tab \> `Record Contribution`, or API4)
3. Choose any Financial Type and Amount, set Status to `Pending`
4. View the Contributions list
## Current behaviour
The status shows as `Pending (Incomplete Transaction)`
Then `Edit` the contribution, don't make any changes, just hit `Save`
Note that the status is now `Pending (Pay Later)`
## Expected behaviour
Should be `Pending (Pay Later)`
## Environment information
* **CiviCRM:** _Master & 5.70.0 - maybe others_
Reproducible on dmaster.demo.civicrm.org
## Comments
_See_ https://chat.civicrm.org/civicrm/pl/qcmoueddmfbm7bpfq4uauympcwhttps://lab.civicrm.org/dev/core/-/issues/5069standalone: permanent "session already active" errors2024-03-26T14:20:29ZRichstandalone: permanent "session already active" errorsEvery page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* sessi...Every page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* session_start(): Ignoring session_start() because a session is already active [8]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 580
I first encountered this while reviewing https://github.com/civicrm/civicrm-core/pull/29352 but after experiencing it once, I could not get it to repeat, so thought it was a random local thing. But now it's back.
I have some installs that don't have it, and others that do; I'm trying to figure out how to reproduce/what makes the difference.https://lab.civicrm.org/dev/core/-/issues/5068Do we need the qfkey in group urls?2024-03-07T13:49:27ZAndrew WestDo we need the qfkey in group urls?My users are forever emailing each other broken links to Civi groups, due to the qfkey in the URL. This doesn't seem to be needed in most of the rest of Civi - is it worth my investigating how to remove it? Or would we aim to replace tha...My users are forever emailing each other broken links to Civi groups, due to the qfkey in the URL. This doesn't seem to be needed in most of the rest of Civi - is it worth my investigating how to remove it? Or would we aim to replace that page with a search kit version soon anyway?https://lab.civicrm.org/dev/core/-/issues/5067Docker image - initial version2024-03-08T09:40:10ZMichael McAndrewDocker image - initial versionFor the initial image, we will focus on CiviCRM Standalone with a simple implementation of layer 3 (see #5066). While we are retaining a narrow focus for the initial release, the Design principles and scope #5066 are an attempt to future...For the initial image, we will focus on CiviCRM Standalone with a simple implementation of layer 3 (see #5066). While we are retaining a narrow focus for the initial release, the Design principles and scope #5066 are an attempt to future proof this work by considering a wider set of use cases.https://lab.civicrm.org/dev/core/-/issues/5066Docker image - design principles and scope2024-03-13T16:58:38ZMichael McAndrewDocker image - design principles and scope**_This text is draft - feedback welcome_**
We are creating CiviCRM Docker image designed to be used as a building block in the _production hosting_ of CiviCRM (see #5064 for more details). It will support both CiviCRM Standalone and Ci...**_This text is draft - feedback welcome_**
We are creating CiviCRM Docker image designed to be used as a building block in the _production hosting_ of CiviCRM (see #5064 for more details). It will support both CiviCRM Standalone and CiviCRM alongside a CMS.
We expect the image to be used as part of a wider set of tools to create reliable, performant, scalable hosting infrastructure. Creating that infrastructure is outside of the scope of this image and we are agnostic on what tools used to do so. Commonly used tools include Kubernetes, Docker swarm, etc.
The image can also be used as part of a development environment to enable 'dev prod parity'. When we say development environment we are referring specifically to a development environment for production hosting, not a development environment for core CiviCRM development (buildkit etc.).
Note: we will likely encounter limitations in making each CMS 'Docker friendly' that are outside of our control.Note: support for core development workflows (buildkit, etc.) is outside of the scope of this project.
It is based on the following **principles**:
**No surprises**. We'll follow the well trodden path. Use CiviCRM defaults and recommendations, and Docker and cloud best practices, e.g. https://12factor.net/. There are many different opinions about the best way to deploy CiviCRM and we won't be able to please everyone. If you want to do something extra special or clever, then this _might_ not be for you.
**Be conservative about options**. Each option that we add multiplies complexity and increases the chance of bugs and breakages and we'll avoid adding them unless there is a compelling reason. That said, where possible we'll design the image in such a way that it can be used as a base for more opinionated solutions (e.g. by breaking the Docker image into layers).
### Build process
A possible architecture is as follows:
* Layer 1: CiviCRM Dependencies and tools
* Layer 2: CMS/standalone dependencies and tools
* Layer 3: Application source code
Consumers can choose the image that is the most appropriate jumping off point for their infrastructure.
We expect many consumers of this repository will roll their own Layer 3 that makes sense for their own own build process. A simple approach to building a Layer 3 would be to copy a source code tree from a repository. Other options include using CMS tools such as `drush` or `wp` or dependency managers like `composer`.
We could consider swapping the order of Layers 1 and 2 and rely on official CMS builds as the base layer. This would save time but mean we were reliant on the upstream base images and need to deal with any variance between them. It is worth noting that the Drupal and WordPress images on Docker hub are maintained by the Docker community, not the projects themselves.
### Configuration
We should consider patching CiviCRM to allow it to consume settings passed as environment variables (or similar).
### Backing services
All 'backing services', including MySQL, email delivery, payment providers, etc, are outside the scope of this image and are expected to be configured via environment variables or similar.
We may consider creating recommended images for backing services (e.g. MySQL, email services) further down the line.
### Admin processes
We will include existing tools like `cv` and `civix` to assist with the execution of one off admin processes (e.g. upgrades, config changes, etc.) These tools are also useful during development.
There are some admin processes, e.g. backups, snapshots, for which there are currently no official tools. We should consider creating these as part of this project.
We may also include cron for scheduled tasks.
### Port binding
The image wil expose CiviCRM (and the CMS via http on a specific port. Reverse proxies, caches, firewalls, etc. are outside of the scope of this project.
### Concurrency
The image will be designed to support horizontal scaling, i.e. running multiple instances of the image in parallel.
### Logs
All logs (CiviCRM, Apache, PHP) will be sent to stdout/stderr.https://lab.civicrm.org/dev/core/-/issues/5065Docker image - review of existing CiviCRM Docker codebases2024-03-13T21:32:52ZMichael McAndrewDocker image - review of existing CiviCRM Docker codebasesAs part of https://lab.civicrm.org/dev/core/-/issues/5064 we would like to review existing CiviCRM Docker codebases **_that are currently being used for production hosting_** in order to distil existing best practice and also to not repe...As part of https://lab.civicrm.org/dev/core/-/issues/5064 we would like to review existing CiviCRM Docker codebases **_that are currently being used for production hosting_** in order to distil existing best practice and also to not repeat previous mistakes.
If you have an existing CiviCRM Docker based solution that you would be willing to share, please add a link below with some narrative and pointers for us.
Some questions it would be great if you could answer:
- What is working well for you in your current set up?
- What the challenges have you experienced? / what problems are yet to be solved?
- Are the any Docker APIs or features that you are not making use of that you think would be useful
- anything else you think is relevanthttps://lab.civicrm.org/dev/core/-/issues/5064An official CiviCRM docker image2024-03-12T16:30:24ZMichael McAndrewAn official CiviCRM docker imageWe'd like to create an official CiviCRM Docker image that people can use as a building block when creating CiviCRM hosting infrastructure.
This issue is as an overview with links to various sub-tasks, some of which have issues linked be...We'd like to create an official CiviCRM Docker image that people can use as a building block when creating CiviCRM hosting infrastructure.
This issue is as an overview with links to various sub-tasks, some of which have issues linked below.
1. Review existing Docker based set ups and collect best practice #5065
2. Design principles and scope #5066
3. Develop initial version of the image #5067
4. Create publishing infrastructure
5. Sketch roadmap for further development
6. Document how to use and contribute to the project
This project has received funding from SFE's CiviClick project (thank you SFE!) which will help kick start things but won't cover everything we need to do.
SFE are also funding improvements to CiviCRM to make it more Docker friendly and a project to orchestrate CiviCRM using Kubernetes. See https://cloud.software-fuer-engagierte.de/index.php/s/KrTmxnxH5AZYzg4 for the users stories that this work is intended to cater for.https://lab.civicrm.org/dev/core/-/issues/5063Payment Processor shows Machine Name instead of Backend Title in Configure Ev...2024-03-07T13:44:21Za.valllloveraPayment Processor shows Machine Name instead of Backend Title in Configure Event FeeCurrently the Machine Name of the Payment Processor is shown instead of the Backend Title in Configure Event Fee.
![image.png](/uploads/8029ab7c4e2e343a7adcd43b9ff57bbd/image.png)
![image.png](/uploads/15041218f9d5c10911b5b3d4c5e72fcb/...Currently the Machine Name of the Payment Processor is shown instead of the Backend Title in Configure Event Fee.
![image.png](/uploads/8029ab7c4e2e343a7adcd43b9ff57bbd/image.png)
![image.png](/uploads/15041218f9d5c10911b5b3d4c5e72fcb/image.png)
In Event:
![image.png](/uploads/d8ed15dd94db3f41c2c6ac93ed4544cc/image.png)
Additionally, this means that is meaningless to rename the Backend Title since it will not be displayed. Seems that is getting the `name` field instead of the `title` field.
The tests were made in Master.
EDIT: Seems the problem is here: [PseudoConstant.php](https://github.com/civicrm/civicrm-core/blob/2b410a28eb62e3fc0ada7df712e538794cd06efa/CRM/Core/PseudoConstant.php#L978)https://lab.civicrm.org/dev/core/-/issues/5062APIv4: Cannot set multi-select ContactRef field that is part of a multi-recor...2024-03-07T15:44:13ZmmyriamAPIv4: Cannot set multi-select ContactRef field that is part of a multi-record custom fieldsetOverview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom f...Overview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom field set for all Individuals and check "Does this Custom Field Set allow multiple records?"
2. Add a ContactRef field and check "Multi-Select"
3. Try to set it via the APIv4 Explorer
![image](/uploads/44ecbf788a66150425e55a9de8a6212f/image.png)
Current behaviour
----------------------------------------
Failing with error:
```
{
"error_code": 0,
"error_message": "value: \u00013\u000193\u0001 is not of the right field data type: ContactReference",
"status": 500
}
```
Environment information
----------------------------------------
https://dmaster.demo.civicrm.org running 5.72.alpha1
Comments
---
Not an issue if the multi-select ContactRef field is not part of a multi-record custom fieldset.https://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-25T20:55:29ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Ok, but it smells bad to have columns belonging to one component in another component's table :nose: (fixme for another day) |
| `<localize_context>` | ✅ keep | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | Historically this was inferred by `<type>` but a few fields explicitly declare `<crmType>` |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename/reorganize | `attributes` | `type` gets moved out (see `<html><type>` below), while `length` gets moved in as `maxlength` |
| `<html><type>` | ⚠️ move/rename | `input_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/5060Automated reminder to people that didn't subcribe to groups they applied subs...2024-03-14T22:45:20Znikola.mladenovicAutomated reminder to people that didn't subcribe to groups they applied subscription forOverview
----------------------------------------
Subscribing for newsletter usually ends up as a one way street, if they want to have subscribers and be under wing of GDPR. If the user doesn't confirm their subscription, they would eith...Overview
----------------------------------------
Subscribing for newsletter usually ends up as a one way street, if they want to have subscribers and be under wing of GDPR. If the user doesn't confirm their subscription, they would either have to find original email or resubscribe if they cant find it, but usually users just forget they did subscribe.
Recommended improvement was discussed on Mattermost to check if such feature existed in civicrm and few users did raise concern and that they would like to have this feature request:
[Mattermost chat](https://chat.civicrm.org/civicrm/pl/bg6x9u7qmf8fdkwn8tz4o9ft1r )
Current behaviour
----------------------------------------
Subscribing to newsletter only sends email as user applies for newsletter
Proposed behaviour
----------------------------------------
Scheduled job for example, which would check if there are any users which are pending for some groups, check the date they applied and then send another nudge for user to join in. This feature should be limited to only once per fresh request for all pending users. Proposal for after how much this automated schedueld job would contact users should be a week, 2 weeks, month, 2 months, 3 months.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/5058FormBuilder "magic" links should log in the user so that User-based Entity se...2024-03-07T13:41:11ZKeith NunnFormBuilder "magic" links should log in the user so that User-based Entity security behaves as expectedOverview
----------------------------------------
When sending a link to a Form Builder form to a user by token (e.g. {afform.afformSubmissionLink}), the generated URL provides information that allows the form to auto-populate. It should...Overview
----------------------------------------
When sending a link to a Form Builder form to a user by token (e.g. {afform.afformSubmissionLink}), the generated URL provides information that allows the form to auto-populate. It should also log in the specific contact who received the link similarly to the behaviour of the contact_id and checksum tokens when used together.
Reproduction steps
----------------------------------------
1. create a new basic submission form
1. set 'Expose to:' to include 'Message Tokens'
1. set 'Individual 1' Security to 'User-based'
1. set 'Autofill' to 'current user'
1. Go to a contact summary page and merge document to use the exposed token.
1. Follow the link in the merged document
Current behaviour
----------------------------------------
Sometimes the form will throw an error, other times if the overall display permissions are open enough, the form will display and auto-populate, but any changes to the Individual 1 contact record will fail.
Expected behaviour
----------------------------------------
CiviCRM should recognize the user as a logged-in contact because we have sent them a 'magic' link.
Environment information
----------------------------------------
https://wpmaster.demo.civicrm.org test environment via firefox 123
Comments
----------------------------------------