CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-07-17T05:03:23Zhttps://lab.civicrm.org/dev/core/-/issues/2496Api support for afform contribution pages2023-07-17T05:03:23ZeileenApi support for afform contribution pagesAfform what do we need to do to offer Contribution form
Contribution entity - but just basic fields
Payment block
To do the latter we need an api like
PaymentForm with the actions
```
->submit
->getfields
->validate
```
```payment_pro...Afform what do we need to do to offer Contribution form
Contribution entity - but just basic fields
Payment block
To do the latter we need an api like
PaymentForm with the actions
```
->submit
->getfields
->validate
```
```payment_processor_id ``` would be required for each of these (getfields would reply with metadata that would indicate what additional fields are required)
That should be the minimum for a totally basic processor (like paypal std, paypalpro, dummy, payment express, Mollie, Sagepay recurring in Omnipay, some IATS)
All the complexity comes in when we start adding in the js - e.g Stripe, Paypal checkout, some IATS. I think it makes much more sense to get the easy ones working first - but once they are then for phase 2 we will need at minimum
- An api function to get the JS to add with some details about it
- A js object on the pay to return the total_amount from the form - this is something Matt has been working on & would need to be thought through across forms - eg. CRM.PaymentForm.getAmount() should do the same on the angular form and on the core civicrm forms. We probably need to articulate what other functions it may or may not need
On submission we would do
```
Order.create (this can just be the same params as Contribution.create in the initial submit. At minimum it is basically contribution.create with a forced ‘Pending’ status
PaymentProcessor.pay
Payment.create
```
These exist in apiv3 & I think we would use them for nowhttps://lab.civicrm.org/dev/core/-/issues/347Buttons inconsistencies2023-07-12T11:52:57ZAkA84Buttons inconsistencies# Problem
While working on Shoreditch I spent some time doing an inventory of the different variations, in terms of markup, of a button in civi (it's not fully comprehensive, for example i left out the "disabled" versions) and it looks t...# Problem
While working on Shoreditch I spent some time doing an inventory of the different variations, in terms of markup, of a button in civi (it's not fully comprehensive, for example i left out the "disabled" versions) and it looks to me that there are several inconsistencies that civi would benefit from addressing or at least mitigating
![buttons](/uploads/c2b53a6da6be011b62195255395dfc5c/buttons.png)
_(source: https://gist.github.com/AkA84/9cfcfa610971461493dee1e63c0e06fb)_
## 1. Too many ways of doing the same thing
Right now there are several ways to add a standard civi button to a page, and all of them with caveats:
1. Use the `.button` class, but only if you apply it to a `<a>` or a `[type="button"]`
2. Use the `.crm-button` class, but it won't work correctly if you apply it to a `<a>`
3. Use the `.crm-form-submit` class, but only if you apply it to a `input[type="button"]` or a `input[type="submit"]`
4. Use the plain tag without classes, but only if it's `[type="button"]`, as either `<button>` or `[type="submit"]` will not be styled
Ideally there should be only one class that provides the desired state (say, `.crm-button`). Just like it works in Bootstrap (http://getbootstrap.com/docs/3.3/css/#buttons)
## 2. There are differences to the style in each variation
The differences are mostly about padding, which in turn cause the height to vary
1. `a.button` has a padding of `2px 6px`, resulting in a height of 23px
2. `span.button` has a padding of `1px`, resulting in a height of 20px
3. `button.crm-button` has a padding of `3px 6px` resulting in a height of 24px
4. `input[type="button"]` and `input[type="submit"]` have the same padding of `a.button`, but probably because of how they are rendered by the browser they end up with a different height, 19px
5. `.crm-button input[type=button]` has a padding of `3px 5px 2px`, resulting in a height of 22px
6. `.crm-button .crm-form-submit` has a padding of `1px 8px 2px 4px`, resulting in a height of 21px
It gets pretty evident once you line them up
![heights](/uploads/4901d492dca87220731572f8dfa45583/heights.png)
## 3. Some variations are floated by default
`a.button` and `span.crm-button` are floated by default to the left, which is pretty confusing. Not sure why this layout decision was hardcoded on these variations, but it prevents one to use them without having to "counter" the floating each time
# Solution
I think issue no.2 is the one with the better chances of being fixed without introducing regression issues, as it's just about consolidating the padding and height of all the variations
Issues no.1 and no.3 instead I can imagine that if fixed would likely cause problems downstream. At the very least some documentation of what should be the correct/preferred way to add a button in a civi page should mitigate the confusion and eventually lead to an adoption of a single variation as the "right" one over the others, which over time would become legacy and could eventually be removed
Shoreditch of course should be able to correct most if not all of the above by simply overriding the original css, but I thought worth flagging the problem anyway as it might be worth considering addressing the problems in the original "theme" as wellhttps://lab.civicrm.org/dev/core/-/issues/2440Contact Custom Fields not automatically populating upon creation2023-07-10T05:03:24ZswebervnaContact Custom Fields not automatically populating upon creationOverview
----------------------------------------
When the public accesses our donation page and donates, it'll automatically create a contact for them. And for all contacts, I have a set of custom fields with **default** values, but I'v...Overview
----------------------------------------
When the public accesses our donation page and donates, it'll automatically create a contact for them. And for all contacts, I have a set of custom fields with **default** values, but I've noticed that some (or most) new contacts don't have these fields automatically populated - to set them, you have to click on them and click **Save**. This is a problem for us because we frequently run reports, and without these fields populated they can miss our reports. It would be tedious to have to manually set and save these fields for each new contact.
Current behavior
----------------------------------------
1. New contact custom fields:
![image](/uploads/3ccf2c3b29aa841750af4bfc414ea5fc/image.png)
2. When you click on the custom fields:
![image](/uploads/de3c243fe46a1140b37c9d481ed0bb7b/image.png)
3. When you click **Save**:
![image](/uploads/de81d753ebd639a925d2bbedb1400b33/image.png)
(Fields are set as they should be done automatically)
```
Expected behavior
----------------------------------------
Upon a new contact created, CiviCRM should automatically populate these custom fields with their default values, so they can accurately show up on Reports.
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 necessary. -->
* __Browser:__ _Chrome 88.0.4324.190_
* __CiviCRM:__ _5.33.2_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _(Unknown)__
* __CMS:__ _Drupal 7.?_
* __Database:__ _(Unknown)_
* __Web Server:__ _(Unknown)_https://lab.civicrm.org/dev/core/-/issues/2258Re-Thinking our Crypto implementation2023-07-09T05:03:24ZseamusleeRe-Thinking our Crypto implementation_Motivation_:
We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted wit..._Motivation_:
We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted within the database e.g. Payment Processor Passwords.
_Problems_:
1. Not easily able to determine what Crypto method has been used (Mcrypt or Base64 encoded only) to save the SMTP password.
2. Not easily to assess which extensions have had fields encrypted (e.g. know that Sparkpost has encrypted their API key but other than that unsure)
3. Relies on CIVICRM_SITE_KEY (which is maybe over-using that value).
4. Linked to Item 2, is there is no way for the API/DAO/Extensions to know what fields have been encrypted so to decrypt code appropriately.
_Potential ideas_:
1. Create a setting which stores the encryption class and use a factory / hooks to allow for extensions to customise which crypto library to use within CiviCRM
2. Have a hook / use some level of meta data to determine if a field is to be encrypted
_Discussion Questions_:
1. Should we completely break CRM_Utils_Crypt class as we re-work the encryption within the app
2. How should we handle switching between Crypto libraries?
3. Should extensions be able to use their own Crypto Library whilst leaving rest of the App to use a system specific Crypto?
4. Do we want to allow for civicrm.settings.php defines / environment variable overrides for encrypted fields / data points?https://lab.civicrm.org/dev/core/-/issues/2454Access Control by Financial Type permissioning does not cover contribution_recur2023-07-08T05:03:19ZandyburnsAccess Control by Financial Type permissioning does not cover contribution_recurWhen having _Access Control by Financial Type_ turned on a user without the permission over a given financial type can still access it in 3 ways:
- Can view corresponding recurring contribution (under recurring contributions tab)
- Can ...When having _Access Control by Financial Type_ turned on a user without the permission over a given financial type can still access it in 3 ways:
- Can view corresponding recurring contribution (under recurring contributions tab)
- Can cancel it
- Can view all contributions related to the recurring. So it is a backdoor around the permissioning.
I've checked the financial type in civicrm_contribution_recur and it is one they should not see.
![cancel-recurring](/uploads/f514ebffe682dfa823c54512a9a5b505/cancel-recurring.png)
![recurring-contritbutions-log](/uploads/a28ecf0d139ff3c11c1b3aad320576f3/recurring-contritbutions-log.png)
WP 5.6.2 Civi 5.31.1https://lab.civicrm.org/dev/core/-/issues/2456Explore use of JWTs for authentication2023-07-07T05:03:19ZcolemanwExplore use of JWTs for authentication(*Migrated from a totten comment on another thread about simulating permissions in afform and searchkit*)
## JSON Web Tokens: Microsoft example
(*This example demonstrates the data-flow. Many symbols/URLs are edited to improve readabil...(*Migrated from a totten comment on another thread about simulating permissions in afform and searchkit*)
## JSON Web Tokens: Microsoft example
(*This example demonstrates the data-flow. Many symbols/URLs are edited to improve readability/intuition.*)
A "JSON Web Token" (JWT) is a building-block for an access-control system. (Analogy: JSON serves a purpose like XML... but JSON is easier to encode/decode/remix/improvise. Similarly, JWT serves a purpose like ASN.1/X.509... but JWT is easier to encode/decode/remix/improvise.)
Microsoft uses JWT for their web-service APIs - and also for email APIs, like MS Exchange Online. When Civi talks to MS Exchange Online, it uses JWTs. In this process, a user "Alice" (`alice@example.com`) starts out in Civi web UI. We redirect her to `https://login.microsoftonline.com`, where she clicks a button to say "Yes, trust CiviCRM", and (long-story-short) MS sends us an access token.
This access token looks like a long, random password (`aSdF12.34QwErTy.DvORak`), and we can use it to make REST calls. For example, we might request a copy of Alice's user profile:
```
GET https://api.microsoft.com/about-me HTTP/1.1
Authorization: Bearer aSdF12.34QwErTy.DvORak
```
```
HTTP/1.1 200 OK
Content-type: application/json
{"email": "alice@example.com", "first_name": "Alice", "last_name": "Alison", ...}
```
Again, it looks like a password, so one can plug it into many different systems. We can use it to connect to IMAP or SMTP servers.
But it's not really a password. It is encoded JSON. If you clean it up, then it looks like this:
```js
{
"issuer": "login.microsoftonline.com",
"user": "alice@example.com",
"scopes": ["imap", "smtp", "profile"],
"expires": "2021-04-08 12:16:20"
}
```
This says that `login.microsoftonline.com` (the master security service at Microsoft) is vouching for us. We're approved to access a few services (`"scopes":["imap", "smtp", "profile"]`) on behalf of a particular person (`"user": "alice@example.com"`). When we connect to `api.microsoft.com` or IMAP or SMTP, the server parses the JWT, validates the signature cryptographically, and then gives us access.
The fields (`user`, `scopes`, etc) determine access control. If we try to access any other API -- editing Alice's address book, deleting Word docs, generating maps, etc -- then it will reject us. That's because our `"scopes"` do not include `address_book`, `manage_docs`, or `mapping`.
The token format doesn't *have* to be based on JSON or JWT. Civi's email hashes are a fine example of a token that doesn't use JSON. However, JSON is flexible and easy to parse. If you're designing a protocol, you have a lot of latitude to pick and choose which fields to include. Additionally, because it's standard, it's easier to inspect/debug. (Got a failed request? Decode the JWT and see if anything looks wrong.)
## JSON Web Tokens: Why
Why would someone like Microsoft adopt an access-token pattern like JWT?
Because they are actually running many distributed apps - and, when you get to a certain scale (#apps/#devs/#users), it gets hard to think straight (or run performantly) if they are linked-up one-by-one using a shared session.
Ordinarily, one would expect the demands on a self-hosted PHP app to be gentle enough to address with a straight-forward session/global variable (`$session->get('userID')`; `global $user`). There's a lot of mileage there. However, with the complexity of supporting multiple CMSs with different routing/session/identity mechanisms -- and with the goal of doing targeted permission escalations/changes/bypasses -- I'm not so sure. Civi is not positioned to be as simple as a singular PHP app - maybe it's more like a distributed app (where access+identity messages are coordinated among many different components - Drupal, Joomla, WordPress, Civi QF, Civi APIs, etc)
## Browser (JS) apps and alternative permissions
OK, so how would you use JWT to accomplish alternate permissions in a Civi/JS/Angular/API app?
Recall that the page-load goes a bit like this:
```
GET https://example.org/civicrm/search HTTP/1.1
Cookie: SESS=abcd1234
GET https://example.org/civicrm/ajax/api4/SavedSearch/get?name=foobar HTTP/1.1
Cookie: SESS=abcd1234
GET https://example.org/civicrm/ajax/api4/Contact/get?complexCriteria=... HTTP/1.1
Cookie: SESS=abcd1234
```
In each request, the permissions are determined by the cookie. But you don't want those permissions. So... don't use the cookie. Use something with different permissions - like a JWT.
```
GET https://example.org/civicrm/search HTTP/1.1
Cookie: SESS=abcd1234
GET https://example.org/civicrm/ajax/api4/SavedSearch/get?name=foobar HTTP/1.1
Authorization: Bearer aSdF12.34QwErTy.DvORak
GET https://example.org/civicrm/ajax/api4/Contact/get?complexCriteria=... HTTP/1.1
Authorization: Bearer aSdF12.34QwErTy.DvORak
```
During the initial page-view, you have to construct and output the token. This is where you decide what kind of actions will be permitted. Maybe it looks like:
```php
$token = Civi::service('crypto.jwt')->encode([
'exp' => time() + 3600,
'scopes' => ['api4/SavedSearch/get', 'api4/Contact/get'],
]);
Civi::resources()->addSetting('apiAuthToken', $token);
```
or maybe:
```php
$token = Civi::service('crypto.jwt')->encode([
'exp' => time() + 1800,
'scopes' => ['SavedSearch:foobar'],
]);
Civi::resources()->addSetting('apiAuthToken', $token);
```
or:
```php
$token = Civi::service('crypto.jwt')->encode([
'exp' => time() + 3600,
'contactId' => 1234,
'savedSearch' => 'foobar',
'perms' => ['access AJAX API']
Civi::resources()->addSetting('apiAuthToken', $token);
```
This is a very generic/flexible way to think about changing permissions while supporting AJAX apps.https://lab.civicrm.org/dev/core/-/issues/441Proposal - Add Timezone support for all Date/Time fields in CiviCRM2023-07-02T19:22:33Zjustinfreeman (Agileware)Proposal - Add Timezone support for all Date/Time fields in CiviCRMAdd Timezone support for all Date/Time fields in CiviCRM. Currently, CiviCRM does not have any timezone handling for date/time fields - timezone is not stored with the value.
The first change is to start storing a timezone with the date...Add Timezone support for all Date/Time fields in CiviCRM. Currently, CiviCRM does not have any timezone handling for date/time fields - timezone is not stored with the value.
The first change is to start storing a timezone with the date/time field. After this is implemented then other changes can follow which deal with the display of the date/time field in the local time zone or showing the timezone for the value.
**Proposed Change**
Have ability to set the timezone for a date/time field and store that value with the field.
Default timezone should set using the CMS timezone default and/or a new setting on the Localisation Settings page.
Agileware Ref: CIVICRM-995https://lab.civicrm.org/dev/core/-/issues/2417Proposal add support for latin American preferred language2023-07-02T05:03:20ZeileenProposal add support for latin American preferred languageCurrently when editing the preferred language for a contact we have these 3 spanish options
![image](/uploads/123b26710174bc10869c2cc79d2b17c2/image.png)
Our standard appears to be the IETF language tag
https://en.wikipedia.org/wiki/La...Currently when editing the preferred language for a contact we have these 3 spanish options
![image](/uploads/123b26710174bc10869c2cc79d2b17c2/image.png)
Our standard appears to be the IETF language tag
https://en.wikipedia.org/wiki/Language_code
![image](/uploads/e630095633c71b8de1194a4008452681/image.png)
However, we don't offer es-419 "Spanish appropriate for the Latin America and Caribbean region, using the UN M.49 region code"
This ommission is not just at the option value level - but at the schema level. In order to support this language variant we need to alter the schema to accept 6 rather than 5 characters for the preferred_language field
```
<field>
<name>preferred_language</name>
<title>Preferred Language</title>
<type>varchar</type>
<length>5</length>
```
@bgmhttps://lab.civicrm.org/dev/core/-/issues/2386Support chain-select elements in .setting.php files2023-07-01T05:03:24ZJonGoldSupport chain-select elements in .setting.php filesOverview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Local...Overview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Localization » Languages, Currencies, Locations**.
1. The `defaultContactStateProvince` setting can't be represented accurately via metadata.
Current behaviour
----------------------------------------
No way to define either an `onclick` value or a chain-select.
Proposed behaviour
----------------------------------------
A new property `chain_select_settings` contains properties that are passed to the `addChainSelect` method.
Comments
----------------------------------------
There's partial support, and I suspect work on this stopped because `addChainSelect` has a syntax that's tangled up in Smarty. I'll submit a PR to be a conversation piece.
This will also need documentation.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/533Update recaptcha to v32023-06-30T05:03:20ZMartinUpdate recaptcha to v3Google recaptcha v3 has now been officially released:
https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html
Obviously v2 is still working for the time being but it would be beneficial to update core to use v...Google recaptcha v3 has now been officially released:
https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html
Obviously v2 is still working for the time being but it would be beneficial to update core to use v3. For example one of our clients is currently seeing this issue (significant usability bug in iOS):
https://github.com/google/recaptcha/issues/130
Thanks!https://lab.civicrm.org/dev/core/-/issues/2401Unable to include seconds in date format for display2023-06-28T05:03:20Zfreeform.stephUnable to include seconds in date format for displayWe would like to include seconds when viewing date fields in reports, the option "%S" does not work (displays "%S" instead of the seconds value).
Reproduce: on Localization > Date format, change the value of "Date Format: Complete Date ...We would like to include seconds when viewing date fields in reports, the option "%S" does not work (displays "%S" instead of the seconds value).
Reproduce: on Localization > Date format, change the value of "Date Format: Complete Date and Time" from the default "%B %E%f, %Y %l:%M %P" to "%B %E%f, %Y %l:%M:%S %P" and load a report displaying a date column, you'll see something like "January 4th, 2021 3:28:%S PM".
First reported on stack exchange: https://civicrm.stackexchange.com/questions/38869/date-and-hour-format-with-secondshttps://lab.civicrm.org/dev/core/-/issues/2399Add new property to Phone entity to mark a number as a mobile phone or the pr...2023-06-28T05:03:19ZhomotechsualAdd new property to Phone entity to mark a number as a mobile phone or the primary SMS number.Overview
----------------------------------------
_Currently we don't have a straightforward way to say "this is a mobile phone/cell phone number" we have the `phone_type` property but being an option group it's inherently unreliable and...Overview
----------------------------------------
_Currently we don't have a straightforward way to say "this is a mobile phone/cell phone number" we have the `phone_type` property but being an option group it's inherently unreliable and subject to change. If we were looking for a way to say "this phone number is a mobile phone - use it for sending SMS" we're kinda out of luck!_
Current behaviour
----------------------------------------
_We can try to infer whether a phone number is for a cell phone by checking for phone_type but it's unreliable and we can't reliably rely on a single ID designating a mobile phone number (or that any of them do!)_
Proposed behaviour
----------------------------------------
_An explicit property that denotes that a number is a cellphone/mobile number or alternatively a property that denotes that that number is the preferred for SMS e.g `is_smsprimary`._https://lab.civicrm.org/dev/core/-/issues/495CQ: Migrate simple Preferences & Settings forms to using a Generic class.2023-06-27T05:03:25ZeileenCQ: Migrate simple Preferences & Settings forms to using a Generic class.Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the cl...Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the class 'CRM_Admin_Form_Preferences_Event' and all classes that don't need special sauce would be removed & the xml would be altered to
```
<item>
<path>civicrm/admin/setting/preferences/event</path>
<title>CiviEvent Component Settings</title>
<page_callback>CRM_Admin_Form_Generic</page_callback>
</item>
```
This page would load settings based on filtering setting metadata - so any fields with a key in their metadata like this
```
settings_pages => [
'event' => ['weight' => 10]
]
```
would show up at the url above (note the last value on the url is the filter).
Extensions could use the existing alterSettingMetadata hook to add & remove fields from any pages that use the Generic form to choose their settings and extensions could add settings pages by just adding an xml entry & their metadata
We would convert simple forms & for more complex forms we would attempt to break the inheritance on the 2 existing forms (CRM_Admin_Form_Preferences & CRM_Admin_Form_Setting) in favour of using just the CRM_Admin_Form_SettingTrait in an attempt to grandfather them out.https://lab.civicrm.org/dev/core/-/issues/2393Settings metadata help_text parameter doesn't work and causes errors if you s...2023-06-27T05:03:25ZDaveDSettings metadata help_text parameter doesn't work and causes errors if you specify it but there's no .hlp fileNot sure if I'm going to follow this thru but am recording some findings. There's at least 3 things to deal with:
1. There's no facility to specify the title of the help box. This is the easiest since it can compute it from the setting ...Not sure if I'm going to follow this thru but am recording some findings. There's at least 3 things to deal with:
1. There's no facility to specify the title of the help box. This is the easiest since it can compute it from the setting label.
2. CRM.help _does_ support passing a single string as the help content, but you get into quote-hell pretty quickly.
3. The `{help}` plugin which is what generates the `<a>` link that calls CRM.help doesn't have a way to accept a string as the help content, and `{help}` is what SettingForm.tpl uses. \
3.b Related note: the `{help}` plugin behaves differently whether you pass it a title parameter or not. If there's no parameter it expects to find it inside an associated .hlp file.
Earlier related issue: https://lab.civicrm.org/dev/core/-/issues/1920https://lab.civicrm.org/dev/core/-/issues/2208Enforce default country setting globally2023-06-26T05:03:15ZandyburnsEnforce default country setting globallyIf you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used...If you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used in listings mode.
Noting @JonGold made an extension that solves this: https://civicrm.stackexchange.com/questions/20986/show-default-country-and-state-for-public-proximity-searchhttps://lab.civicrm.org/dev/core/-/issues/2378Status of relationships is not under the control of administrators2023-06-24T05:03:19ZUpperholmeStatus of relationships is not under the control of administratorsOverview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control...Overview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control of administrators, and nor is it explicit under what circumstances the nature of a given relationship might change.
https://civicrm.stackexchange.com/questions/28465/how-do-relationships-become-disabled
I raised the question nearly two years ago, and since that time there have been a number of responses on the SE site, some of which I find quite surprising. What is evident is that there are circumstances where a given relationship becomes disabled without the explicit knowledge or consent of administrators. As far as I'm aware there are no settings to control these behaviours.
In my own case I look after a site where memberships are a key driver. The members are organisations, and the memberships are configured such than individuals with an employee/employer relationship have the benefit of membership. This includes inclusion on mailing lists which are driven by smart groups, access to member-only content, event discounts, etc.
What I'm seeing is that employee/employer relationships are often disabled, despite the fact that the team that manages the CRM very rarely uses start or end dates for relationships (we rarely have this information). So, when a relationship is created it should stay enabled until such time as it is manually disabled. We'll manually disable a relationship relatively rarely, when we get information that a person has changed jobs or retired, but this is really very infrequent.
What does happen a lot with our system is that records get merged. People register on the site for events, or sign up for a mailing list, etc., and provide inaccurate information which often leads to duplicate records getting created. So there is a regular day to day activity of spotting and merging duplicates. It is therefore my guess - and it is purely guesswork - that it is this act of merging which is leading to relationship records getting disabled.
What should happen:
-------------------------
If there are rules that are working in the background that are leading to relationships getting disabled, and the information in the Stack Exchange post suggests that there are, then these should be:
1. Made explicit in the documentation, and
1. Controls should be provided either in the UI (preferably), or via the civicrm.settings.php file, whereby site administrators can enable or disable these rules of behaviour.
1. Where a suitably privileged user carries out an action that results in a relationship being disabled an on-screen alert should be displayed, with a link to enable the user to override that disablement.
If there are no rules or background systems that are driving these silent disablements, then there's a nasty bug.https://lab.civicrm.org/dev/core/-/issues/298API Explorer shows incorrect syntax for arrays via drush/cv2023-06-24T05:03:19ZJonGoldAPI Explorer shows incorrect syntax for arrays via drush/cvThe problem I'm seeing is displayed in the attached screenshot. When you create an API call with API Explorer that requires the use of an array, API Explorer adds the array, JSON-encoded, to the argument list. However, neither drush no...The problem I'm seeing is displayed in the attached screenshot. When you create an API call with API Explorer that requires the use of an array, API Explorer adds the array, JSON-encoded, to the argument list. However, neither drush nor cv (and I assume wp-cli) will parse the argument as an array. This has tripped up multiple folks on Stack Exchange ([1](https://civicrm.stackexchange.com/questions/10887/can-i-chain-api-calls-through-drush), [2](https://civicrm.stackexchange.com/questions/16423/passing-json-objects-to-drush-cvapi)).
As answers to those SE questions point out, it IS possible to use drush/cv and encode arrays. Instead of:
```
cv api Contact.create contact_type="Individual" first_name="Jon" options={"match":"first_name"}
```
We could do:
```
echo '{"contact_type":"Individual","first_name":"Jon","options":{"match":"first_name"}}' | cv api Contact.create --in=json
```
There are three solutions of increasing effort, depending on how important folks think this is. I'm willing to do the first one, and someone else can do 2 or 3 if they feel it's important.
1) Patch API Explorer so drush/cv/wp always show the (more complex) `echo foo | cv api bar.baz --in=json` syntax.
2) Patch API Explorer so drush/cv/wp show the more complex syntax when an array is present (I can do this if it's simple, I'd have to look).
3) Patch drush/wp/cv to match API Explorer.
![Selection_544](/uploads/1335415c85a5e6aaf9f185c023ce4c25/Selection_544.png)https://lab.civicrm.org/dev/core/-/issues/19disabled optionvalues are not shown in participant export2023-06-23T17:54:22ZJoostdisabled optionvalues are not shown in participant exporta participant field has a custom field containing option values. Participants choose one of these option values. The option value that the participants chose gets disabled after they chose it. In a participant export containing this cust...a participant field has a custom field containing option values. Participants choose one of these option values. The option value that the participants chose gets disabled after they chose it. In a participant export containing this custom field the participants who chose for the disabled option will have a blanc space in the table on that location. Expected is having the option they chose over there, all-tough it has been disabled, and isn't available to choose any more.
to recreate this on a demo site:
1. create a participant to the fall fundraiser dinner with a soup preference
1. go to custom fields and edit the food preference custom field
1. deactivate the soup selection you chose in step 1
1. find participants to the fall fundraiser dinner
1. select all participants and export them using 'select fields to export'
1. select the fields to export:
- individual - display name to find the person you gave the food selection to
- participant - food preference: soup selection the field we are interested in
1. open the exported file. The soup selection for the disabled field isn't in there. When there are participants who chose for a soup that is still active the soup selection is in there for themhttps://lab.civicrm.org/dev/core/-/issues/10Enabling plugin in CKEditor Default doesn't enable it in Civimail despite sho...2023-06-23T17:54:21Zluke.stewartEnabling plugin in CKEditor Default doesn't enable it in Civimail despite showing it as enabledWhen enabling a CKEditor plugin at: civicrm/admin/ckeditor if you add it to "Default" and press save.
At this point the plugin shows up on all three tabs, (Default, Civimail, CiviEvent) however the plugin doesn't appear on a new mail des...When enabling a CKEditor plugin at: civicrm/admin/ckeditor if you add it to "Default" and press save.
At this point the plugin shows up on all three tabs, (Default, Civimail, CiviEvent) however the plugin doesn't appear on a new mail despite clearing caches, and force refreshing the browser.
Navigating to the "Civimail" tab and pressing save there as well gives the desired behaviour that the plugin is enabled.![CKEditor](/uploads/5c8b21a886fbf4b0eb27cd0a0ba0d09d/CKEditor.png)
Tested on 4.7.27 and 4.7.31RC
To reproduce:
1. Navigate to civicrm/admin/ckeditor
1. Select a plugin from the plugin dropdown on the default tab
1. Obeserve additional component appears in preview
1. Click Save
1. Clear caches civicrm/admin/setting/updateConfigBackend
1. Create an new email -> civicrm/mailing/send?reset=1
1. Observe additional component that it doesn't show in the toolbar.
1. Return to civicrm/admin/ckeditor
1. Shift to the Civi mail tab. Observe the plugin is listed.
1. Scratch head.
1. Press save.
1. Create a new mail.
1. You now have the required plugin.
I haven't tested behaviour with regards to the event tab.https://lab.civicrm.org/dev/core/-/issues/2375Feature request, De-duplicate rules for Organisations would be more useful if...2023-06-23T05:03:20Zjustinfreeman (Agileware)Feature request, De-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value fieldDe-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value field. Thereby allowing multiple Nicknames (or aliases) for the same organisation to be recorded.
Currently de-duplicate rules for Orga...De-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value field. Thereby allowing multiple Nicknames (or aliases) for the same organisation to be recorded.
Currently de-duplicate rules for Organisations are limited by up to 5 fields. So if you have Organisation Name, Nickname and Email then there are only two fields remaining to compare, which could be used for two custom (Organisation) Nickname fields. You could possibly have a multi-valued custom field for Nickname 2 - have not confirmed if that works at all for de-duplication.
However, it is more commonplace for Organisations to have multiple different abbreviations and shortened versions, not by some "official" naming standard, but simply because people refer to the Organisation differently with varying spelling and abbreviations. eg. IBM, I.B.M, IBM Inc. IBM Intl.
This is a feature request. Open for discussion about other solutions or implementation.
Agileware Ref: CIVICRM-1666