Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-10-20T07:58:08Zhttps://lab.civicrm.org/dev/wordpress/-/issues/145Merge tags for communication preferences and unsubscribe incorrect in Mosaico...2023-10-20T07:58:08ZchristodhunterMerge tags for communication preferences and unsubscribe incorrect in Mosaico mailingsWe have a preferences block in our Mosaico template which looks like this:
`<a href="{CommunicationPreferences.comm_pref_supporter_url}" style="text-decoration: underline; color: #FFFFFF; font-weight: 600;">Update communication preferen...We have a preferences block in our Mosaico template which looks like this:
`<a href="{CommunicationPreferences.comm_pref_supporter_url}" style="text-decoration: underline; color: #FFFFFF; font-weight: 600;">Update communication preferences</a><br>
<a href="{action.unsubscribeUrl}" style="text-decoration: underline; color: #FFFFFF; font-weight: 600;">Opt out of all communications</a>`
When the mailing goes out, the location of the Mosaico template is prepended to the links, so they end up like this:
`<a href="https://www.XXX.org.uk/wp-content/uploads/civicrm/mosaico_tpl/XXX/https://www.XXX.org.uk/civicrm/gdpr/comms-prefs/update/?reset=1&cid=64128&cs=04e32b40536295bc9b37d124ecfe51ce_1696349918_240" style="text-decoration: underline; color: #FFFFFF; font-weight: 600" target="_new">Update communication preferences</a><br>
<a href="https://www.XXX.org.uk/wp-content/uploads/civicrm/mosaico_tpl/XXX/https://www.XXX.org.uk/civicrm/mailing/unsubscribe/?reset=1&jid=&qid=&h=fakehash" style="text-decoration: underline; color: #FFFFFF; font-weight: 600" target="_new">Opt out of all communications</a>`
This is on:
CiviCRM 5.65.2
Mosaico 3.2.1691060437
WordPress 6.3.1https://lab.civicrm.org/dev/core/-/issues/4635ACL's causing invalid SQL2023-12-21T00:30:37Zaydunsaidan.saunders@squiffle.ukACL's causing invalid SQLI've just been tracking down a problem where calls to `CRM_Contact_BAO_Contact_Permission::allow()` result in a DB syntax error.
The problem is in `CRM_ACL_BAO_ACL::getGroupClause()` see [here](https://github.com/civicrm/civicrm-core/b...I've just been tracking down a problem where calls to `CRM_Contact_BAO_Contact_Permission::allow()` result in a DB syntax error.
The problem is in `CRM_ACL_BAO_ACL::getGroupClause()` see [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/ACL/BAO/ACL.php#L506-L536).
`$groupIDs` is set but only contains invalid or inactive groups, so the `$foundGroupIDs` is empty resulting in the invalid SQL: `... WHERE group_id in ( ) AND ...`5.67.0https://lab.civicrm.org/dev/core/-/issues/4568Attempting to move a custom field of type Country bypasses extends check and ...2023-09-13T19:40:30ZtechnomazAttempting to move a custom field of type Country bypasses extends check and failsMoving custom fields that are extended from two different types (e.g. individual to membership) is not allowed by code. The check works fine for alphanumeric fields, properly showing an error in the UI. However, when attempting to move a...Moving custom fields that are extended from two different types (e.g. individual to membership) is not allowed by code. The check works fine for alphanumeric fields, properly showing an error in the UI. However, when attempting to move a field with a type of Country, the check appears to be bypassed or is not working for some reason. The system attempts to begin database alter statements, failing in the background, while the CiviCRM logo endlessly spins in UI.
This is one error that was thrown during that attempt:
```
[nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`dbname`.`civicrm_value_individual_me_1`, CONSTRAINT `FK_civicrm_value_individual_me_1_entity_id`
FOREIGN KEY (`entity_id`) REFERENCES `civicrm_membership` (`id`) ON DELETE CASCADE)]
```
This appears to be the check that works for alphanumeric fields, but is not being thrown for Country fields:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomField.php#L20075.67.0https://lab.civicrm.org/dev/core/-/issues/4556"Check number" field isn't shown on Pending check payments (workaround exists)2023-12-12T19:08:26ZAllenShaw"Check number" field isn't shown on Pending check payments (workaround exists)(Similar to behavior described in https://lab.civicrm.org/dev/core/-/issues/60)
**One way to repro this on dmaster.demo.civicrm.org:**
1. Log in and navigate to any contact record.
2. Create and save a contribution with these attributes...(Similar to behavior described in https://lab.civicrm.org/dev/core/-/issues/60)
**One way to repro this on dmaster.demo.civicrm.org:**
1. Log in and navigate to any contact record.
2. Create and save a contribution with these attributes:
- Status: Pending
- Payment method: Check
3. Observe this contribution is displayed in the contact's Contributions tab.
4. Open the contribution for viewing, and select the "Record Payment" link or button; this opens the New Payment form.
5. In the New Payment form, observe that the Payment Method is pre-selected as "Check".
6. Observe expected vs actual (bad) behavior:
- Expected behavior: Because the Payment Method is "Check", the field "Check Number" should be displayed for data entry
- **Actual (bad) behavior:** "Check Number" field is not displayed.
**Workaround:**
Continuing from Step 6 above: Change the Payment Method to anything other than "Check", then change it back to "Check". Observe that the "Check Number" field is now available for data entry.
Screencap of problem and workaround from dmaster.demo.civicrm.org today:
![anim](/uploads/f951056d3c2c0c91aaff0d6f17a8b1b4/anim.gif)
(Joinery reference: F#1220)https://lab.civicrm.org/dev/core/-/issues/4545Events - Self service and change options after initial registration2023-09-06T13:20:42ZtreseroEvents - Self service and change options after initial registrationThis is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Jo...This is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Joe wants to add this to his registration.
Scenario 2: Joe now realizes that he wants to add his wife.
Scenario 3: Joe's friend Jeff wants to go, and also play golf.
You get the idea.
As Events is now, there is no way to adjust your registration and it has to be done manually. That is not an option for 700 - 800 registrations run by all volunteers (i.e. we don't have any paid staff). Another issue is we can't make the payment required as it would have to be paid when there is a "new" change. Making it optional, well, you can see the problem.
My thinking would be to look up email, or something and populate the form etc. We already require them to create a wordpress account so that could also be used. It's just not there.
Also, we have 25,000+ constituents that were imported from a legacy system. They don't have any accounts, but it would be nice if there were a way to match emails (where possible, I know not all have updated/current emails), but this is a less important scenario.
I have coding skills, but as we are all volunteers, I don't have much time. There is some money to budget for a developer. All code will be added back to the public.
![image.png](/uploads/9e7d2100f9b61ee6b871d0467d58338d/image.png)
As you can see, this is an example. Of course, none is not an option. but if we added other additions, or they want to add another person, it has to be manually done.https://lab.civicrm.org/dev/core/-/issues/4542ACLs' priority sometimes does the opposite of what it says it does2023-09-13T05:50:38ZRichACLs' priority sometimes does the opposite of what it says it doesWhen you're editing an ACL the **priority** field says:
> Higher priority ACL rules will override lower priority rules
![image](/uploads/445064fd12b8757ab42f221708abf3f1/image.png)
It appears that the relevant code is at [civicrm/CRM/...When you're editing an ACL the **priority** field says:
> Higher priority ACL rules will override lower priority rules
![image](/uploads/445064fd12b8757ab42f221708abf3f1/image.png)
It appears that the relevant code is at [civicrm/CRM/ACL/BAO/ACL::loadPermittedIDs()](https://github.com/civicrm/civicrm-core/blob/804dc3e1707f7d2baf0747016ca32370c8652e54/CRM/ACL/BAO/ACL.php#L459)
and this code orders by Priority ascending.
1. If the ACL grants(or denies) access to a *particular* group(/object) then it processes every ACL in turn, meaning, it works as described because the last one will have the last say; higher priority means higher priority.
2. But if it grants(or denies) access to *all* groups(/objects) then it **stops at the first one**, with a `break`. So the **lower priority** takes it.
So for rules that refer to "all" groups(/other entities), priority is reversed(!)
I'm not sure about the code in that loop
- if it's an Allow all groups(/objects) rule for the current permission type (Edit/View), then we do an odd loop to append the keys of allGroups to ids which seems odd: why not do `$ids = array_keys($allGroups);` and save on duplicates/time/code?
- if it's a Deny all groups(/objects) rule, then there's an `array_diff()` but if you remove *all* then surely that's just clearer as `$ids = [];`?
- Finally, if it's an ACL that affects *all* groups(/objects) but the *first* ACL doesn't match on permission type (e.g. we're looking for Edit perm and the first one found grants View), then there's a `break`. **This is the cause of the priority reversal**, but it also 'breaks' :laughing: other potential configurations. e.g.
- there's no point in having 2 rules about 'all' groups(/objects) - e.g. one for edit and one for view - the one with the lowest priority prevents Civi ever considering the 2nd. If that's because edit also grants view (does it?) then we ought to stop people making such rules in the UI.
- rules like: Grant edit to all groups, followed (higher priority) by a deny group X won't be honoured.
I *think* the correct thing to do here is just get rid of that `break`.
PIng @seamuslee who authored a recent [relevant commit](https://github.com/civicrm/civicrm-core/commit/b2f5462a066fa7dd36dc9281cb24af097391327a)5.66.0seamusleeseamusleehttps://lab.civicrm.org/dev/joomla/-/issues/53[Joomla 4.0] Mosaico build screen clipped (maybe a Mosaico issue)2023-09-06T10:36:42Znicol[Joomla 4.0] Mosaico build screen clipped (maybe a Mosaico issue)Mosaico is loaded in an iFrame, with a fixed position that is lost behind the Joomla UI:
![image](/uploads/752b2ea5a9ccc68e0fe8daedd0e023fe/image.png)
something like
`#crm-mosaico {
left: 288px;
top: 66px;
width: calc(100vw - 288px);...Mosaico is loaded in an iFrame, with a fixed position that is lost behind the Joomla UI:
![image](/uploads/752b2ea5a9ccc68e0fe8daedd0e023fe/image.png)
something like
`#crm-mosaico {
left: 288px;
top: 66px;
width: calc(100vw - 288px);
height: calc(100vh - 66px);
}`
would work if the Joomla sidebar is extended and
`#crm-mosaico {
left: 48px;
width: calc(100vw - 48px);
}`
if it isn't, but there's no helpful Joomla classes to differentiate between these states via a parent selector. Even if that was fixed, to avoid having to force this with `!important`, may be better to address this in Mosaico's absolute positioning script..https://lab.civicrm.org/dev/core/-/issues/4532Add sort for country/state fields in reports2023-08-24T15:17:42ZyashodhaAdd sort for country/state fields in reportsAdd sort for country/state fields in reportsAdd sort for country/state fields in reports5.66.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4531Afform - Email link doesn't render on individual emails for contacts with pre...2023-09-02T05:12:01ZtottenAfform - Email link doesn't render on individual emails for contacts with preferred localeOverview
----------------------------------------
Afform allows you define email tokens that make quick-links to a form (eg `{afform.afformProfileUrl}`). The token doesn't render in certain contexts.
This issue was identified by @larss...Overview
----------------------------------------
Afform allows you define email tokens that make quick-links to a form (eg `{afform.afformProfileUrl}`). The token doesn't render in certain contexts.
This issue was identified by @larssg in MM (https://chat.civicrm.org/civicrm/pl/rwsgdztjpfbx5dgcpqkzw6x6se). It appears to be a regression circa 5.54. It does not affect CiviMail.
Reproduction steps
----------------------------------------
1. Setup a D7 site. (D8+ and BD should have the same bug.)
1. Find or create an afform. Ensure that it has a URL and email token.
1. Find or create a contact. Ensure that **Preferred Language** is configured.
1. View the contact (`civicrm/contact/view`). Use **Actions: Send Email** to send a message with the token (e.g. `{afform.afformProfileUrl}`)
1. Check the email
Current behavior
----------------------------------------
In the resulting email, the token appears blank.
Expected behavior
----------------------------------------
The token shows a URL/hyperlink.
Comments
----------------------------------------
Under the hood, here are some key ingredients:
* afform registers for token events via [afform_civicrm_config()](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/core/afform.php#L63-L67), which includes a static-guard against re-registration.
* 5.54 included various updates with an aim toward supporting localized email. Consequently, while sending the email, it calls `CRM_Utils_System_*::setUFLocale()`.
* On D7/D8+/BD, `setUFLocale()` calls this:
```php
// Config must be re-initialized to reset the base URL
// otherwise links will have the wrong language prefix/domain.
$config = CRM_Core_Config::singleton();
$config->free();
```
* Consequently, the next time anything calls `CRM_Core_Config::singleton()`, it will reboot the container. This effectively removes any listeners. For afform, the listeners are lost.https://lab.civicrm.org/dev/core/-/issues/4530Search forms - email validation smashes usability2023-09-02T05:12:01ZeileenSearch forms - email validation smashes usabilityWe hit this recently in QF search forms but now I'm seeing it in search forms based on search kit - the email validation means I can't search for an email
@colemanw
![image](/uploads/b4faf0bde8b64ef7eef3d281a907aac5/image.png)We hit this recently in QF search forms but now I'm seeing it in search forms based on search kit - the email validation means I can't search for an email
@colemanw
![image](/uploads/b4faf0bde8b64ef7eef3d281a907aac5/image.png)https://lab.civicrm.org/dev/wordpress/-/issues/143Plugin compatibility architecture and loss of locale on "Secondary URLs" when...2023-12-06T16:01:59ZhaystackPlugin compatibility architecture and loss of locale on "Secondary URLs" when using PolylangThis issue covers a couple of related matters:
1. A better architecture for providing compatibility with 3rd party plugins
2. Loss of locale on "Secondary URLs" when using Polylang
The first item is necessary in order to implement the ...This issue covers a couple of related matters:
1. A better architecture for providing compatibility with 3rd party plugins
2. Loss of locale on "Secondary URLs" when using Polylang
The first item is necessary in order to implement the second in a reliable fashion. It also has consequences for #133 but I think that @shaneonabike will appreciate the new architecture as a way of better encapsulating WPML support in its own class. Hopefully we can move forward with that issue as well now.
The PR for this issue on CiviCRM-WordPress requires the related PR on CiviCRM-Core. In combination, they solve the following problem:
When Polylang is active, locale is lost on "secondary" or "internal" URLs built by CiviCRM Core. For example, on an Event Info screen (https://example.org/fr/civicrm/event/info/?reset=1&id=3) the "Register" link does not retain the current front-end locale but instead contains no locale information at all (https://example.org/civicrm/event/register/?id=3&reset=1). With the PRs applied, the link becomes https://example.org/fr/civicrm/event/register/?id=3&reset=1 and retains the locale as defined by Polylang.
PR links to follow.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/4524Tax calculate wrong on Membership signup page2023-12-19T22:19:50ZPradeep Nayakpradpnayak@gmail.comTax calculate wrong on Membership signup pageCiviCRM: 5.64.1
PHP - 8.1
Replicate:
**Financial Account**
1. Tax 1, type=liability, is tax = checked, tax rate= 16%
2. Tax 1, type=liability, is tax = checked, tax rate= 13%
**Financial Type**
1. Assign tax 1 as Sales tax account is ...CiviCRM: 5.64.1
PHP - 8.1
Replicate:
**Financial Account**
1. Tax 1, type=liability, is tax = checked, tax rate= 16%
2. Tax 1, type=liability, is tax = checked, tax rate= 13%
**Financial Type**
1. Assign tax 1 as Sales tax account is to Member dues FT
2. Assign tax 2 as Sales tax account is to Donation FT
**Price Set**
Create a price set to FT = member dues and extends=Membership.
Price fields:
1. Membership, select HTML type, membership type General, amount= 84.48, FT= Member dues
2. Misc, select HTML type, label='Zero', Amount=0, FT=Campaign
3. Donation, Text HTML type, unit price=0.89
Create Online membership page, FT=Member dues and use the price set created above under membership section.
Try doing a online submission
![Screenshot_2023-08-22_at_15.02.05](/uploads/ea2da6a60b5d12483801580b250d4ff3/Screenshot_2023-08-22_at_15.02.05.png)
**Expected Result:**
![Screenshot_2023-08-22_at_15.03.28](/uploads/7fff93e304bc73f6adb312c8a90a828f/Screenshot_2023-08-22_at_15.03.28.png)
**Actual result**
![Screenshot_2023-08-22_at_15.02.49](/uploads/3d3af70ea32b2a5c5bac95cfb5df18c2/Screenshot_2023-08-22_at_15.02.49.png)5.69.0https://lab.civicrm.org/dev/core/-/issues/4521CiviCRM 5.64.1 update does not always enable core extension CiviContribute wh...2023-09-18T23:43:03Zjustinfreeman (Agileware)CiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSODCiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSOD, throwing an error:
`Error: Class 'Civi\Api4\EntityFinancialAccount' not found in CRM_Financial_BAO_FinancialType::getIncomeFinancialType(...CiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSOD, throwing an error:
`Error: Class 'Civi\Api4\EntityFinancialAccount' not found in CRM_Financial_BAO_FinancialType::getIncomeFinancialType() (line 171 of .../civicrm/CRM/Financial/BAO/FinancialType.php).`
OR
`Uncaught Error: Class 'Civi\Api4\PaymentProcessorType' not found`
This is because the **civi_contribute** extension has not been enabled / loaded yet, which is part of a set of core-bundled extensions that map to each CiviCRM component.
This seems to occurs more regularly when an extension update is available for a Payment Processor or other extension which calls on the missing class from CiviContribute.
Can be manually solved by running `cv en civi_contribute` on the CLI. Sometimes the website UI is inaccessible after this error and CLI is only method available to recover.
This error also seems to interrupt the enabling of other core-bundled extensions, eg. CiviReport, CiviMail, CiviEvent etc.
CiviCRM 5.64.1
Agileware ref: CIVICRM-2163https://lab.civicrm.org/dev/joomla/-/issues/52Cannot have a CiviCRM-link menu as default (home) page2024-03-07T23:14:49Zthoni56Cannot have a CiviCRM-link menu as default (home) pageIn Joomla you declare one menu item to be the default "front page" i.e. the one that you get to when no menu is selected, only the web sites base path.
In J3 this also worked for a menu entry that was a CiviCRM-entry, such as Event List...In Joomla you declare one menu item to be the default "front page" i.e. the one that you get to when no menu is selected, only the web sites base path.
In J3 this also worked for a menu entry that was a CiviCRM-entry, such as Event Listing or Mailing List Subscription. (check e.g. https://events.responsive.se which is a J3 site with Event Listing as the default menu entry.)
With J4 this no longer works. When going to the "home page" the menu item is highlighted to indicate that it is active, but there is no output in the content area.
I tried this with a clean J4 and CiviCRM and see the same thing. The underlined "Subscription" indicates that it is the menu entry that is active.The J4 default template Cassiopeia displays breadcrumbs which strangely enough shows "Home" and not "Subscription" (which is the menu entry for CiviCRM Mailing List Subscription form).
This is extra strange because the breadcrumb for the Home menu entry is actually "Home/Home" so the default page Subscription is something in between...
![image.png](/uploads/e82c3a451f5ed6010968e4d25c17d6a5/image.png)Explicitly clicking the "Subscription" menu entry correctly shows the form.
I don't really know enough about Joomlas routing to understand where the problem really is, but I'm starting by reporting it here.https://lab.civicrm.org/dev/core/-/issues/4514AdminUI: Manage ACLs - An ACL mode set to 'Deny' is stored OK but still shows...2023-08-25T08:23:45ZAndy ClarkAdminUI: Manage ACLs - An ACL mode set to 'Deny' is stored OK but still shows on the list of ACLs as 'Allow' (5.64)In 'Manage ACLs' a new mode of 'Allow' or 'Deny' has been added. When you set an ACL to 'Deny' it is correctly stored but in the list of ACLs always shows as 'Allow'.In 'Manage ACLs' a new mode of 'Allow' or 'Deny' has been added. When you set an ACL to 'Deny' it is correctly stored but in the list of ACLs always shows as 'Allow'.seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/4501Redis performance issue on delete contact2023-09-23T05:08:34ZeileenRedis performance issue on delete contactWe have a process where we merge contacts and then delete the deleted contacts after a period of time.
However, we have more or less never run the delete deleted contacts script because it is too slow. I dug into it today and found that...We have a process where we merge contacts and then delete the deleted contacts after a period of time.
However, we have more or less never run the delete deleted contacts script because it is too slow. I dug into it today and found that
- on staging it takes 15 seconds to delete 500 contacts
- on production it takes 6-10 minutes to delete 500 contacts
I've spent most of the day digging into why & determined that the queries run are identical & timings are similary. However, on production each time this line of code runs ` Civi::service('prevnext')->deleteItem($id);` it takes a bit over 1 second. This is not the case on staging because there are no users populating the prevnext cache with searches. Hence I have diagnosed that the problem is having users & the solution is to lock their accounts.
More specifically the issue is that the code is going through all the Redis keys to remove the contact - which seems to be inefficient.
![image](/uploads/701ae2d41d47d0eae49ee118f80d4dc4/image.png)
I did wonder if a quick-fix would be to only call `deleteItem` if the contact is not already deleted (which they are in our use case) - I would need to change [the find to fetch here](https://github.com/civicrm/civicrm-core/blob/aef17937a6d1bf00d2ca446bf3c5fc81644b3b92/CRM/Contact/BAO/Contact.php#L907-L911) I think...
Alternatively there is probably some option around queuing the cache clear to happen at the end. However, I think that 1 second + delay is actually not great for users either - e.g when deduping a bunch of contacts than having each form submit take that bit longer would add up.
We are on the cusp of getting `coworker` going so pushing something to a queue to clear out caches might be an option.https://lab.civicrm.org/dev/core/-/issues/4484Feature request: New contact buttons on the API 4 autocomplete widget2023-11-01T18:20:41ZbrienneFeature request: New contact buttons on the API 4 autocomplete widgetOverview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such a...Overview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such as for selecting a Contributor on a backend contribution.
![Selection_015](/uploads/30fc0ecdd3268ebc5906ce0aa06dae9a/Selection_015.png)
Example use-case
----------------------------------------
1. Add the *Existing Contact* field to a FormBuilder form
1. A user can look up a contact to select, but if there are no results/a new one is needed, they can click a **New Individual** button to add one without being redirected from the original form
Current behaviour
----------------------------------------
The APIv4 autocomplete widget does not allow for creating new contacts.
![Selection_014](/uploads/d97659f7dddfd4858bd316acb0dda2b6/Selection_014.png)
Proposed behaviour
----------------------------------------
The APIv4 autocomplete widget should have feature parity when it comes to creating new contacts on the spot as the Select2 optionhttps://lab.civicrm.org/dev/core/-/issues/4472Index not created for ACL priority on upgrade to 5.642023-09-02T05:11:59ZJonGoldIndex not created for ACL priority on upgrade to 5.64Once upon a time we had a "missing indexes" check that was removed because it wasn't always easy to auto-solve the issues.
I still run that check in an extension, and on every site I've upgraded to 5.64, I get a notification that `index...Once upon a time we had a "missing indexes" check that was removed because it wasn't always easy to auto-solve the issues.
I still run that check in an extension, and on every site I've upgraded to 5.64, I get a notification that `index_priority` hasn't been added to `civicrm_acl.priority`.5.64.1https://lab.civicrm.org/dev/core/-/issues/4466Roles - Define default taxonomy (for standalone deployments)2023-12-04T21:13:40ZtottenRoles - Define default taxonomy (for standalone deployments)Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* ...Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* __Light-touch with open taxonomy.__ This is what D7 does -- you just get 2-3 roles (anonymous, authenticated, admin). Then the site-builder can fill-in more roles to taste. When you upgrade, you may need to re-tune the roles.
* __Strong defaults with hackable taxonomy__ This is what WP does -- you get several roles out-of-the-box. Site-builders are not particularly encouraged to refine them, but it is possible (esp using APIs/add-ons). When you upgrade, it can (*I assume*) add or update roles.
* __Library of example roles__: This idea comes from looking at Google Cloud -- they have an extensive library of roles. Some of the roles are similar/overlapping (e.g. there are older and newer flavors of "File Admin"/"Storage Admin"). The upshot is that you get a presumption of continuity while still allowing the taxonomy to evolve. The downside is that the list is a bit overwhelming. But treating these as templates might mitigate that (*library of possible roles is long -- but the local site only enables a handful*).
There are some related questions - if you have strong defaults or a library of examples, then how do you deal with extensions (*i.e. the list of available perms may fluctuate depending on the extensions*).https://lab.civicrm.org/dev/core/-/issues/4459Uncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLoca...2023-08-04T12:51:55ZyurgUncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLocationTypeLabel() must be of the type string, null returnedOverview
----------------------------------------
WordPress contacts import from CSV, CiviCRM 5.61.2. (not reproduceable on dmaster).
https://civicrm.stackexchange.com/questions/45332/contacts-import-issue-at-crm-contact-import-form-map...Overview
----------------------------------------
WordPress contacts import from CSV, CiviCRM 5.61.2. (not reproduceable on dmaster).
https://civicrm.stackexchange.com/questions/45332/contacts-import-issue-at-crm-contact-import-form-mapfieldgetlocationtypelabel
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Import Contacts**.
2. Add a CSV file, leave all settings intact and click **Continue**.
3. Got a Wordpress WSOD and php error log message "**Uncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLocationTypeLabel() must be of the type string, null returned in /data/sites/web/pedesdev/www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.php:480**".
Expected behaviour
----------------------------------------
Process to the next import step
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* CiviCRM: 5.61.2
* PHP: 7.4.3
Comments
----------------------------------------
Fixed by changing from
- protected function getLocationTypeLabel($type): string {
to
- protected function getLocationTypeLabel($type): ?string {
in www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.php:480
however not sure if this is the right way.