Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-09-03T15:17:35Zhttps://lab.civicrm.org/dev/core/-/issues/1855Allow different output formats for CiviReport results, like native excel form...2020-09-03T15:17:35ZDaveDAllow different output formats for CiviReport results, like native excel format, and untangle codeThis [started as a question](https://github.com/civicrm/civicrm-core/pull/17145) like "without having to patch core or adding another `if outputformat == 'x'` into some already awkward code in core, how can an extension implement a new o...This [started as a question](https://github.com/civicrm/civicrm-core/pull/17145) like "without having to patch core or adding another `if outputformat == 'x'` into some already awkward code in core, how can an extension implement a new output format for civireport results?"
My own motivation for this is a couple things:
1. I've had to look at the related code blocks more than once and it takes at least 15 minutes just to wade through and get to a point where you can start looking into what you were originally trying to look into. Then you get lost again while circling back.
1. I like the idea of being able to prevent people sending me listings of contacts in *pdf* format. No I will not import or analyze this data you've sent me in pdf format. (You can prevent this currently, it would just be easier after.)
1. The email body when sent by the mail_report job is hardcoded. There's been one or two requests to have it be more configurable. You can sort of do it with hook_alterMailParams now but it's not the most robust. I'm not fully addressing that here with any UI changes, but the proposed changes set the stage for it being easier to get there. At the very least you would now be able to write an extension that simply extends the existing handler class (e.g. csv) and overrides the small function that returns the text.
1. I'm currently doing this a different way and don't know if I would switch, but it opens up the possibility for an output handler that provides templates into which the data is inserted which then automatically is available in the existing UI and mail_report job. For most people this would mean a pdf template, but for people like me this means something like an excel template with a prebuilt pivot table and the handler would update the source rows so the pivot would automatically update.
And then beyond my own motivation some other possibilities which are theoretical:
1. A variation of the last point above would be an outputhandler where when run by mail_report it connects to another network service and sends the data there server-to-server. You could set this up via cron exactly the same way you normally use the mail_report job. The equivalent download would then still also be automatically available to users to do manually the same as any other civireport.
## So...
After doing some investigating, can summarize how the current output code works as
* type `sendmail`, which gets the output as a string and sends an email, OR
* type `not sendmail`, which starts a download. Note that "download" technically is also a string, but sent to the browser instead of used in an email.
Then further
* Some of the convoluted nature of the existing code is partly because how to get either of those is different depending on the output format (e.g. csv/pdf/etc).
* Also note that "download" for type 'print' is actually the same as other downloads it's just that you don't need to change http headers first. So that's also adding to the awkwardness a bit in the current code because the way it's written it almost seems like a different code path.
**THEREFORE --->**: My thinking is to start on this by having a common interface to get the string. I mean interface in the general sense of the word, not necessarily OO Interface but maybe. But **then it reduces the number of if/else's to just one**:
* If sendmail,
* Get string (delegated to the output handler).
* Send email (for now extract this to its own function just for readability).
* Else
* Delegate to output handler to set headers and send string to browser (aka download).
There's a little more to it, and it can borrow a bit from the existing PRs, but that's what I'm thinking in terms of first steps to untangling. I will work on a PR.
Then the next steps after that would be to allow for other output handlers, whether it be by a new hook or existing hook or other.
#### Misc notes
* save/copy/delete are handled in beginPostProcess and do nothing in endPostProcess
* there's a difference between compileContent() and the output content. compileContent() is not used for csv, but is used for pdf and 'print'.
* endPostProcess has 4 different "categories":
1. "add contacts to group", which doesn't output anything
2. _sendmail, which uses the other output handlers but requests the results as a string.
* defaults to print, but also does csv or pdf and then exits
* There is also some hardcoding of the email body, partly because it includes a computed url, but it would be nice not to hardcode this.
* Note pdf is called with TRUE for 3rd param, so that it returns the pdf as a string.
3. Download, which uses the other output handlers but requests the results as a download.
* Note that print is a download technically, it just goes to the browser window. Csv or pdf starts an attachment download.
* Here pdf is the default, but at the point in the code where that happens it has to be either print or pdf and print would have been already handled.
* Note pdf is called with FALSE for 3rd param.
* csv is done by a wrapper around the same function that is used in _sendmail
4. Tests that extend CiviReportTestCase use _resultSet/getResultSet() and have _outputMode blank, so endPostProcess (which gets called from preProcess because force=1 here) does none of the above and just stores the results in an array.5.29.0https://lab.civicrm.org/dev/wordpress/-/issues/61undefined offset bug in BAO/FinancialAccount.php2020-07-05T22:25:14Zrgrosundefined offset bug in BAO/FinancialAccount.phpwhile dealing with a white screen, I found a suspicious message in php_errorlog. In debugging that, I think I hit a bug.
- civicrm 5.26.2
- wordpress
In the logging, I see this line:
`[22-Jun-2020 16:58:39 Europe/Amsterdam] PHP Notic...while dealing with a white screen, I found a suspicious message in php_errorlog. In debugging that, I think I hit a bug.
- civicrm 5.26.2
- wordpress
In the logging, I see this line:
`[22-Jun-2020 16:58:39 Europe/Amsterdam] PHP Notice: Undefined offset: 0 in /home/user/public_html/civicrm-nw/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/FinancialAccount.php on line 255`
This notice is triggered by doing a payment after registering for a paid event.
The line that is mentioned in the notice is in function *getFinancialAccountForFinancialTypeByRelationship*; I put in some print statements and found out that it gets value 'Income Account is' in parameter *$relationshipType*. The line of the message uses the hard coded value instead:
`$incomeAccountRelationshipID = array_search('Income Account is', $accountRelationships);`
which is suspicious in itself. But the array $accountRelationships does not contain that value, which causes the message. The array appears to contain the dutch equivalents of the relationships:
```
LOC103 Array
(
[1] => Inkomsten rekening is
[2] => Credit/Contra Revenue Account is
....more
}
```
I am no php programmer, so I fixed it for my site by changing the hard code value to 'Inkomsten rekening is', making the message disappear. I think the code should be changed to somethink like
`$incomeAccountRelationshipID = array_search(translation_of ($relationshipType), $accountRelationships);`5.28.0https://lab.civicrm.org/dev/core/-/issues/1835Export preview not showing data that exists2023-03-28T05:03:44ZStoobExport preview not showing data that existsIn both of these attached cases, the data exists in CiviCRM, and the data is contained in the CSV downloaded upon export. But it is blank in the preview.
![preview](/uploads/82c5b38bb88effd5bb67b6842470111c/preview.png)
![export](/upl...In both of these attached cases, the data exists in CiviCRM, and the data is contained in the CSV downloaded upon export. But it is blank in the preview.
![preview](/uploads/82c5b38bb88effd5bb67b6842470111c/preview.png)
![export](/uploads/a2e1ee8affbeaff3d1377572b080b7f2/export.png)https://lab.civicrm.org/dev/core/-/issues/1834End date default set on Find Contributions to 12:00am eliminates contribution...2020-09-05T21:20:45ZStoobEnd date default set on Find Contributions to 12:00am eliminates contributions made todayUsing the Current Month-to-Date link from the Contribution page the default time is set to 12:00am. This eliminates any contributions "made today". The end time should probably be 11:59pm today, or the next day at 12:00am.
`https://dm...Using the Current Month-to-Date link from the Contribution page the default time is set to 12:00am. This eliminates any contributions "made today". The end time should probably be 11:59pm today, or the next day at 12:00am.
`https://dmaster.demo.civicrm.org/civicrm/contribute/search?reset=1&contribution_page_id=1&force=1&test=0&receive_date_low=20200601&receive_date_high=20200622`
![bunnbuad](/uploads/68779d57eaec0a43b8c8a4a7b77ac472/bunnbuad.png)
![curm](/uploads/0b073ab580660694f99808111fb18a7d/curm.png)`https://lab.civicrm.org/dev/core/-/issues/1830Export not returning addresses properly by location type2023-04-18T05:03:18ZStoobExport not returning addresses properly by location type**Issue 1:**
Select Primary address and is returning the oldest address instead. This is what the underlying data is like:
```
MariaDB [civicrm_crm]> select id,is_primary,contact_id,street_address,location_type_id from civicrm_address w...**Issue 1:**
Select Primary address and is returning the oldest address instead. This is what the underlying data is like:
```
MariaDB [civicrm_crm]> select id,is_primary,contact_id,street_address,location_type_id from civicrm_address where contact_id=5205;
+-------+------------+------------+---------------------+------------------+
| id | is_primary | contact_id | street_address | location_type_id |
+-------+------------+------------+---------------------+------------------+
| 1470 | 0 | 5205 | 317 SW 6th Ave #400 | 2 |
| 13705 | 1 | 5205 | 9755 SW Barnes Road | 3 |
| 13706 | 0 | 5205 | 9755 SW Barnes Road | 6 |
+-------+------------+------------+---------------------+------------------+
3 rows in set (0.00 sec)
```
And this is what is returned.
![neen](/uploads/66248d7e4974b423fe806aaa4acb493a/neen.png)
**Issue 2:**
Select state by Location Main/Work and shows nothing, even though exists. Note: selecting State by Primary location does return results.
![state](/uploads/735e25cdfbc479715a88b32894a8d3dc/state.png)
![main](/uploads/dea0cbd07ecc6fda7687aa3d622b66f2/main.png)
Currently using CiviCRM 5.26.2https://lab.civicrm.org/dev/core/-/issues/1826Dedupe: Location type is treated inconsistently2023-03-18T04:15:46ZJonGoldDedupe: Location type is treated inconsistentlyPer [this Stack Exchange discussion](https://civicrm.stackexchange.com/questions/34671/dedupe-rule-ignores-the-location-type-for-email-phone-but-does-not-ignore-for-ad), there's a UX issue that dedupe ignores location type ID for email a...Per [this Stack Exchange discussion](https://civicrm.stackexchange.com/questions/34671/dedupe-rule-ignores-the-location-type-for-email-phone-but-does-not-ignore-for-ad), there's a UX issue that dedupe ignores location type ID for email and phone but not postal address. The consensus on that page is that we should be consistent in favor of ignoring location type everywhere.
Note that this is a change from the position taken in [https://issues.civicrm.org/jira/browse/CRM-5026](https://issues.civicrm.org/jira/browse/CRM-5026), but I think the 11 years that have passed since that position have given us real-world experience to favor the newly-suggested approach.
I have a patch for this, but no test yet. Once I have a test I'll submit a PR.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1825Merge/bundle flexmailer into core2020-10-23T13:46:59ZbgmMerge/bundle flexmailer into coreFollow-up to: https://github.com/civicrm/org.civicrm.flexmailer/issues/26 - publish a stable version.
Rationale:
* Flexmailer provides cleaner an alternative to a lot of core civimail code
* It adheres to Lexim, in that eventually it w...Follow-up to: https://github.com/civicrm/org.civicrm.flexmailer/issues/26 - publish a stable version.
Rationale:
* Flexmailer provides cleaner an alternative to a lot of core civimail code
* It adheres to Lexim, in that eventually it was meant to replace the core code (i.e. the core code should be flagged as deprecated and eventually removed).
What steps would be required to ship flexmailer in core?
I recall Tim mentioning two options:
* (1) Merge flexmailer in the same way that Api4 was merged, if both versions are highly inter-dependent.
* (2) Bundle flexmailer as a core-extension, similar to sequentialcreditnotes or eventually eventcart (i.e. clearly separate isolation between code bases, but core can assume that the extension is enabled).
I feel like we are more in the second situation, because flexmailer is stable and not tightly coupled with the version of CiviCRM core. However, it may be a bit more work, since we have to tweak the packaging/distribution of CiviCRM?
cc @totten @eileen5.28.0https://lab.civicrm.org/dev/wordpress/-/issues/59Base page is only created on main site in WordPress Multisite2023-02-28T15:26:35ZhaystackBase page is only created on main site in WordPress MultisiteThe default behaviour of CiviCRM on WordPress Multisite is that the base page is not created on every site on which CiviCRM is activated. Instead, the base page is only auto-created on the main site. The absence of the base page on a sub...The default behaviour of CiviCRM on WordPress Multisite is that the base page is not created on every site on which CiviCRM is activated. Instead, the base page is only auto-created on the main site. The absence of the base page on a sub-site can lead to confusion - however it may be the desired behaviour when the WordPress Multisite instance is one where sub-sites are not truly "separate" e.g. sites built on frameworks such as Commons in a Box or MultilingualPress.
Proposed fix: auto-create the base page on all sites on which CiviCRM has been activated but allow plugins to enable the legacy switch to the main site behaviour.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1818Upgrade Angular from 1.5 => 1.82021-05-07T02:27:09ZcolemanwUpgrade Angular from 1.5 => 1.8I'm not sure why CiviCRM core still ships with angular 1.5.
The latest in the 1.x branch is 1.8.
Looking over the [list of breaking changes](https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6) between 1.5 and 1.8, it ...I'm not sure why CiviCRM core still ships with angular 1.5.
The latest in the 1.x branch is 1.8.
Looking over the [list of breaking changes](https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6) between 1.5 and 1.8, it seems pretty minimal.
The biggest change that affects us is the route default has changed from `#` to `#!` https://github.com/angular/angular.js/blob/master/CHANGELOG.md#location-due-to-1https://lab.civicrm.org/dev/core/-/issues/1815Use of the word disable in CiviCRM user screens2023-03-27T05:03:29ZgibsonoliverUse of the word disable in CiviCRM user screensI've been thinking recently about the use of the word 'disable' in Civi. It's used quite a lot in the custom data screens/ relationship screens/ options screens etc.
One suggestion is that this is replaced with activate / deactivate.
Ra...I've been thinking recently about the use of the word 'disable' in Civi. It's used quite a lot in the custom data screens/ relationship screens/ options screens etc.
One suggestion is that this is replaced with activate / deactivate.
Rather than enable / disable.
Although it may be the right use of the word according to a dictionary definition I don't think its appropriate. Twice before this has been pointed out to me directly by training attendees that they are uncomfortable with its use.https://lab.civicrm.org/dev/financial/-/issues/134Contribution confirmation page should not display the name of payment processor2020-09-17T22:57:49Zagileware_pengyiContribution confirmation page should not display the name of payment processor![wording](/uploads/7cf554e3f2ff597d6b001de83e4d299a/wording.png)
The text can simply be: **Click the Continue button to complete the contribution**
[See this line](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/Payment.php#L6...![wording](/uploads/7cf554e3f2ff597d6b001de83e4d299a/wording.png)
The text can simply be: **Click the Continue button to complete the contribution**
[See this line](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/Payment.php#L602) for where it comes from.
Agileware ref: CIVICRM-1496https://lab.civicrm.org/dev/core/-/issues/1801[Activity] Default priority value whed add Activity2020-06-09T01:47:07Zmarcineq[Activity] Default priority value whed add ActivityOverview
----------------------------------------
I use a polish language CiviCRM. When i try create a activity - field "Priority" is empty. The default value doesn't insert into this field.
Reproduction steps
-------------------------...Overview
----------------------------------------
I use a polish language CiviCRM. When i try create a activity - field "Priority" is empty. The default value doesn't insert into this field.
Reproduction steps
----------------------------------------
0. Install CiviCRM with non-english language example polish.
1. Click on **Contacts -> Create activity**.
1. Field Priority is empty.
Current behaviour
----------------------------------------
![image](/uploads/cc5f1c8cd45ed12aaefc9ac819d083e4/image.png)
Priorities in polish:
![image](/uploads/eb91c0bb38a99fe9fd5ba191d06b1691/image.png)
Expected behaviour
----------------------------------------
Priority has selected "Normalny" (it's translated "Normal" value) as default.
Environment information
----------------------------------------
* __CiviCRM:__ _5.24.6 and any earlier version for at least 3 years_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.3/...__
* __CMS:__ _Drupal 7.70/_
* __Database:__ _MySQL 5.7.26-29_
Comments
----------------------------------------
I think I found the cause of the problem, but I don't have the skills to correct it. I'm just an ordinary consultant.
I found a line of code that is responsible for displaying this field in the add activity form. https://github.com/civicrm/civicrm-core/blob/a0f5cb5aff686458dc729ea0a43fbf166f9a8979/CRM/Activity/Form/Activity.php#L585
It shows search "Normal". However, I think that CiviCRM searches in the "Label" column in the database, not "Value" hence after changing the label - this field becomes empty by default.
When I replaced "Normal" on the test version with "Normal" (label in Polish) - the default option appeared correctly.
5.28.0https://lab.civicrm.org/dev/core/-/issues/1790Send email to contacts when clicking on their email address on the contact's ...2020-12-03T14:14:42ZreneolivoSend email to contacts when clicking on their email address on the contact's cardOverview
----------------------------------------
We would like to be able to send emails to contacts when we click on their email address on the contact's card
![gif](/uploads/0526250aed0f562f0f56f3dc2b966e36/gif.gif)
Example use-case...Overview
----------------------------------------
We would like to be able to send emails to contacts when we click on their email address on the contact's card
![gif](/uploads/0526250aed0f562f0f56f3dc2b966e36/gif.gif)
Example use-case
----------------------------------------
1. Hover the contact's icon. The contact's card with their information is going to be displayed.
2. Click on any email address.
3. The email modal should open up populated with the contact's details.
Current behaviour
----------------------------------------
* The contact's card hides as soon as we try to move the mouse on top of the email address.
* When we click on the email nothing happens.
Proposed behaviour
----------------------------------------
* The contact's card should stay open when hovering over it.
* When an email is clicked, it should open with the email modal with the contact's information.
This is useful when checking multiple contacts. We can send an email to one of them without having to open up the contact's details.https://lab.civicrm.org/dev/core/-/issues/1786Report Dashlets and My Reports: Values are not being saved on Access tab2020-06-02T04:47:38ZlottieReport Dashlets and My Reports: Values are not being saved on Access tabOverview
----------------------------------------
I am experiencing an issue where I am unable to generate new report dashlets and unable to add reports to My Reports.
I've tried it on two client sites after another client reported the ...Overview
----------------------------------------
I am experiencing an issue where I am unable to generate new report dashlets and unable to add reports to My Reports.
I've tried it on two client sites after another client reported the issue on their site with the same result. I also tried it on this demo site: https://demo.circle-interactive.co.uk. These are all 5.24.x sites. Since two people reported they were able to generate new dashlets using 5.25.0 (https://civicrm.stackexchange.com/questions/35704/what-happened-to-saving-reports-as-dashlets), I updated one of the sites to 5.25.0 to see if this would solve the issue. It did not.
1. Choose a report that does not have a dashlet already. I used *Contribution Report - Top Donors*.
2. On the *Top Donors >> Access tab*, I enable **Add to My Reports** and **Available for Dashboard** and then **Refresh Results**.
3. Under *Reports >> My Reports*, Top Donor is not shown. Nor is it shown as a dashlet when I view **Configure Your Dashboard**.
What I did discover, is that the values for **Add to My Reports, Available for Dashboard, Limit Dashboard Results and Cache dashlet for** are not being saved. (I've tried this in two browsers: Chrome and Firefox updated to the latest versions.)
Reproduction steps
----------------------------------------
1. Load a report and view the *Access tab*.
2. Update values for **Add to My Reports, Available for Dashboard, Limit Dashboard Results and Cache dashlet for** fields and click **Refresh Results/View Results**.
3. Return to the *Access tab* for the same report and verify that the values are what you set in step 2.
4. Load a different Civi page (such as Report Listing)
5. Return to the *Access tab* for the report where you set you new values. In my case they have reverted to my original values. And no dashlet/no my reports have been added.
What's also strange is that I thought that using the browser's Developer Tool reload option **Empty Cache and Hard Reload** would revert the values; but it did not. It seems that this only happens when I load a new Civi page and then return to the Access tab of the report.
Current behaviour
----------------------------------------
Attempting to assign new values to **Add to My Reports, Available for Dashboard, Limit Dashboard Results and Cache dashlet for** fields fails. They are not saved.
Expected behaviour
----------------------------------------
Values should be saved and if **Add to My Reports** and **Available for Dashboard** are enabled the report should appear in My Reports and as a dashlet.
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. -->
* __Browser:__ _Firefox 76.0.1 (64-bit)/Chrome 83.0.4103.61 (Official Build) (64-bit)
* __CiviCRM:__ _Master 5.25.0 and 5.24.3
* __PHP:__ _7.1, 7.2, & 7.3
* __CMS:__ _Drupal 7.70
* __Database:__ _MySQL 5.7.30 and MariaDB 10.1.44
* __Web Server:__ _Apache/2.4.25
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/1784Contact restore from trash not working2020-06-01T00:07:09ZDaveDContact restore from trash not workingSee also https://civicrm.stackexchange.com/questions/35766/restore-from-trash-not-working-no-related-log-entries
Seems to be from here: https://github.com/civicrm/civicrm-core/commit/8e12bf072fe613c29da39614c8999a4041d7e1d2
In contactT...See also https://civicrm.stackexchange.com/questions/35766/restore-from-trash-not-working-no-related-log-entries
Seems to be from here: https://github.com/civicrm/civicrm-core/commit/8e12bf072fe613c29da39614c8999a4041d7e1d2
In contactTrashRestore() it used to fall through to the code below which does the save(). Then by just copying that block to deleteContact() and calling self::create() it doesn't work because it's expecting `contact_id` not `id`.
So would have started in 5.25.
The quick fix would be to use contact_id. But it sounds like there's a desire to deprecate this entire path of calling deleteContact in order to restore.5.26.0https://lab.civicrm.org/dev/core/-/issues/1767CRM_Dedupe_Finder parses phone key incorrectly2020-07-19T21:43:43Zwil_SRQCRM_Dedupe_Finder parses phone key incorrectlyOverview
----------------------------------------
A profile input form that matches on Phone-Main-Mobile (and I suspect on any phone) sends CRM_Dedupe_Finder::formatParams an input like '["phone-3-1"] => "3214567890"' which after the rel...Overview
----------------------------------------
A profile input form that matches on Phone-Main-Mobile (and I suspect on any phone) sends CRM_Dedupe_Finder::formatParams an input like '["phone-3-1"] => "3214567890"' which after the relevant code around line 255 yields ["phone-3"]. This doesn't match the "phone" in CRM_Dedupe_BAO_RuleGroup::supportedFields so the duplicate check fails.
I patched this by replacing the regular expression in line 255
https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/Finder.php#L255
- **From:** `'/(.*)-(Primary-[\d+])$|(.*)-(\d+|Primary)$/'`
- **To:** `'/(.*)-(Primary-[\d+])$|(.*)-(\d+-\d+)$|(.*)-(\d+|Primary)$/'`
https://civicrm.stackexchange.com/q/35672/5446
Reproduction steps
----------------------------------------
1. Create individual unsupervised rule that matches on phone
2. Create input profile that creates contact with phone-main-mobile and set to "Update the matching contact" on duplicate match
3. Create multiple contacts with same phone
Current behaviour
----------------------------------------
Creates duplicate contacts
Expected behaviour
----------------------------------------
Update pre-existing contact
Environment information
----------------------------------------
* __CiviCRM:__ 5.25.0
Comments
----------------------------------------
I expect you'd prefer I do what's called a "pull request." Apologies, I'm an old retired guy who hasn't programmed for a living in over 35 years so all this new fangled stuff intimidates me. This was an act of desperation on behalf of the nonprofit I volunteer for.
@jaapjansma has created the PR: https://github.com/civicrm/civicrm-core/pull/173615.29.0https://lab.civicrm.org/dev/core/-/issues/1762Don't log subscription_history table2020-05-18T07:51:38ZJKingsnorthDon't log subscription_history tableProblem: If detailed logging is enabled, a lob table for civicrm_subscription_history is created. But that table *is* a log itself. Which stores changes to group membership as new rows.
I cannot see any benefit in logging a logging tabl...Problem: If detailed logging is enabled, a lob table for civicrm_subscription_history is created. But that table *is* a log itself. Which stores changes to group membership as new rows.
I cannot see any benefit in logging a logging table.
Solution:
Suggest that we disable logging of this table by default for new installations, and new instances of logging being enabled.
We could also put a warning message in the update script that this will be disabled by default.
If anyone wants to preserve logging on this table, they could add it back in using hook_civicrm_alterLogTables5.27.0https://lab.civicrm.org/dev/core/-/issues/1757CiviCRM menu toggle "adjust menu position" customisable2023-03-24T05:03:20Zfran@compucorp.co.ukCiviCRM menu toggle "adjust menu position" customisableOverview
----------------------------------------
There are 2 ways for CiviCRM users to show the drupal menu
1. Using ‘hide menu’ dropdown under the CiviCRM main menu, which hides the CiviCRM menu showing only the drupal menu
2. With t...Overview
----------------------------------------
There are 2 ways for CiviCRM users to show the drupal menu
1. Using ‘hide menu’ dropdown under the CiviCRM main menu, which hides the CiviCRM menu showing only the drupal menu
2. With the ‘adjust menu position’ toggle, which moves CiviCRM menu down and shows drupal menu above CiviCRM menu
![menu_toggle](/uploads/b4df0eb1e4164fb43e7e6aac2e570b24/menu_toggle.png)
Most CiviCRM users only use the CiviCRM menu. ‘Adjust menu position’ is most useful for site administrators and ideally would be hidden for all other users.
Current behaviour
----------------------------------------
The menu item ‘adjust menu position’ is available for all CiviCRM users. There is no configuration as with other menu items in the Navigation Menu to define permissions or enable/disable it completely.
Some CiviCRM users who do not use the drupal menu find it confusing seeing both CiviCRM menu and drupal menu together. The ‘hide menu’ already allows access to the drupal menu for these users who need it, and it’s located under the CiviCRM main menu, where the ‘adjust menu position’ is prominent on the CiviCRM menu panel.
Proposed behaviour
----------------------------------------
As there is another way of hiding the civicrm menu ie ‘hide menu’ option and as such most of the sites have been configured in a way that the user is directly taken to the CiviCRM dashboard on login, we suggest the following:
The menu item ‘adjust menu position’ can be configurable so that it can be hidden from basic CiviCRM users.
Acceptance criteria:
1. ‘Adjust menu position’ would be part of the Navigation Menu and be configurable like other menu items
2. Users who could access the Administer menu would have the permission to customise this menu item
3. It would be customisable like other menu items, with the key functionality of being able to set permissions.
![screenshot-compuclient-case-rules-lmi.compubox.co.uk-2020.05.13-11_46_47](/uploads/d16f65a34061aabba1bcec21871d8139/screenshot-compuclient-case-rules-lmi.compubox.co.uk-2020.05.13-11_46_47.png)https://lab.civicrm.org/dev/core/-/issues/1752Allow existing lifetime memberships to be displayed and selected on contribut...2023-03-21T05:03:20ZAllenShawAllow existing lifetime memberships to be displayed and selected on contribution pagesCurrently, if a lifetime membership type is configured to be available on a contribution page, AND if the user has an existing current membership of that type, that membership type is hidden when viewing the live contribution page, and a...Currently, if a lifetime membership type is configured to be available on a contribution page, AND if the user has an existing current membership of that type, that membership type is hidden when viewing the live contribution page, and a help message reads, "You have a current Lifetime Membership which does not need to be renewed.", like so:
--------------
![hidden-explain](/uploads/aaf99afc0b35739844a73203a12b80d9/hidden-explain.png)
--------------
I've encountered a use case in which it's preferable to make this membership type available and selectable, rather than hiding it and explaining why. With small changes to CiviCRM core code (this is not possible with hooks) we're allowing users to complete the contribution form while retaining their lifetime membership, without having to explain to them, "Yes, we know you have a lifetime membership, we're just hiding it from you." Like so:
------------------------------
![displayed](/uploads/b474c63d700e2a0f479e1d9daf5f1251/displayed.png)
------------------------------
I wonder what it might take to get this kind of behavior into CiviCRM core.
This site is maintained by Stuart Gaston, so maybe he'll chime in here with more on the use case and the general rationale for this proposal.https://lab.civicrm.org/dev/core/-/issues/1748Set a default ordering for `get` APIs2023-03-11T05:03:19ZtottenSet a default ordering for `get` APIsOverview
----------------------------------------
In SQL/MySQL, `SELECT` queries accept an option `ORDER BY`. If the option is not given, then the DBMS can choose an arbitrary ordering -- although, *most of the time*, it's a facsimile o...Overview
----------------------------------------
In SQL/MySQL, `SELECT` queries accept an option `ORDER BY`. If the option is not given, then the DBMS can choose an arbitrary ordering -- although, *most of the time*, it's a facsimile of `ORDER BY id`. This creates a false expectation of ordering. This behavior has a knock-on effect - it also applies to API requests.
Example use-case
----------------------------------------
```php
civicrm_api3('Contact', 'get', []);
civicrm_api3('Dedupe', 'get', []);
civicrm_api4('Group', 'get', []);
civicrm_api4('Activity', 'get', []);
```
Current behaviour
----------------------------------------
In absence of an explicit `orderBy` / `sort` option, the `get` API relies on the DBMS's default ordering... which *usually* returns records in order of ID/creation, but it *sometimes* returns records with an arbitrary ordering.
Proposed behaviour
----------------------------------------
In the absence of an explicit `orderBy` / `sort` option, the `get` API should set `ORDER BY id` (*provided that `id` is a sensible column for the given query*).
This makes the actual behavior align reliably with the typical/expected behavior.
Comments
----------------------------------------
A person looking at a typical result-set (esp on a developmental system, with its synthetic data) can incorrectly infer that records are being returned in a sensible order. But they're not - and the misunderstanding can lead to subtle bugs that are difficult to reproduce. (Ex: `SyntaxConformanceTest::testSqlOperators()` has been flaky for a long time and ultimately needed a [patch to use explicit ordering](https://github.com/civicrm/civicrm-core/pull/17251). We only diagnosed the bug by luck -- it was easy to reproduce with one particular entity on one particular version of MySQL.)
Setting the default is a systemic way to prevent this class of bug.