Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-10-15T10:11:56Zhttps://lab.civicrm.org/dev/wordpress/-/issues/20Development roadmap2021-10-15T10:11:56ZhaystackDevelopment roadmapGiven the absence of a formal roadmap for integrating CiviCRM with WordPress, I thought I'd open this issue as a focal point for discussion.
----
### tl;dr:
I would like to integrate the following into the CiviCRM-WordPress plugin:
...Given the absence of a formal roadmap for integrating CiviCRM with WordPress, I thought I'd open this issue as a focal point for discussion.
----
### tl;dr:
I would like to integrate the following into the CiviCRM-WordPress plugin:
* many of the options currently in [CiviCRM Admin Utilities](https://wordpress.org/plugins/civicrm-admin-utilities/)
* new [REST API routes](https://github.com/mecachisenros/civicrm-wp-rest) to replace all `extern/*.php` scripts.
----
### CiviCRM Admin Utilities
There are a couple of issues here that I'd like to address before proceeding.
The first is that CiviCRM Admin Utilities (CAU), when installed, applies its fixes and offers its modifications to *all* versions of CiviCRM, whereas the CiviCRM-WordPress plugin can (obviously) only apply fixes and offer modifications to the current version. This means, for example, that people need to upgrade CiviCRM to make use of new features in the CiviCRM-WordPress plugin.
Secondly, CAU can offer "hot-fixes" for issues as they arise because it is not tied in to the CiviCRM release cycle. This can be a benefit in certain circumstances - especially because it is already resident in the WordPress Plugin Directory and therefore site admins are notified of updates via the WordPress back end. Updating is as simple as, um, hitting "Update".
With that in mind, I do think that there are good reasons to migrate a substantial proportion of the functionality in CAU to the CiviCRM-WordPress plugin. I'll add comments below per option as and when I get a moment to do so.
----
### CiviCRM REST API
Work has begun on a ["CiviCRM WP REST API Wrapper" plugin](https://github.com/mecachisenros/civicrm-wp-rest) which will replace calls to scripts that reside in `civicrm/extern` with routes that do not try and bypass WordPress itself. So far, there is:
* a wrapper for CiviCRM's REST API (i.e. `rest.php`) although it does not yet return XML-formatted results, just JSON
* a replacement for `url.php` which includes a filter for Mailings so that `url.php` is never used
* a replacement for `open.php` which also includes a filter for Mailings but does not (yet) return an image
The reason for this plugin is that those external scripts try to bootstrap WordPress from within CiviCRM even though this is [not possible to do that reliably](https://github.com/civicrm/civicrm-core/pull/11086#issuecomment-335454992). In a WordPress context, therefore, CiviCRM needs to respect this one-way logic and adapt. The REST API wrapper will do that.
One bonus of routing all calls to CiviCRM via WordPress is that a whole heap of [directory](https://github.com/civicrm/civicrm-core/blob/fee4a23bca9fe1e58a44599ca161faf18bbbdce2/CRM/Utils/System/WordPress.php#L530-L583) [traversal](https://github.com/civicrm/civicrm-core/blob/fee4a23bca9fe1e58a44599ca161faf18bbbdce2/CRM/Utils/System/WordPress.php#L75-L121) code can be stripped out of CiviCRM since it is inherently fragile and often self-contradictory. An obvious example of this is the problem of symlinking the CiviCRM plugin directory which, sadly, almost never works as intended.
Another bonus is that [calls to `loadBootStrap()`](https://github.com/civicrm/civicrm-core/search?q=loadBootStrap&unscoped_q=loadBootStrap) become obsolete and [the method itself](https://github.com/civicrm/civicrm-core/blob/fee4a23bca9fe1e58a44599ca161faf18bbbdce2/CRM/Utils/System/WordPress.php#L456-L528) can just `return TRUE` since, after a certain version of CiviCRM, there will be no situations where CiviCRM needs to do so.
There are a number of other scripts in `civicrm/extern` which need to be audited - e.g. does anyone use `cxn.php`? and if so why? Hopefully people can contribute their understanding of these largely undocumented scripts in the comments below - and then REST routes can be created.
----
### Proposal
What I would like to see, therefore, is WordPress-specific development to address WordPress-specific issues. I think this is necessary because some of the functionality cannot be handled by CiviCRM core alone since it may or may not be initialised.
So from my perspective, this means not cluttering "Administer --> System Settings --> CMS Database Integration" with loads of extra options with code held in CiviCRM core. It means using WordPress-native admin pages and WordPress-native functionality implemented via the CiviCRM-WordPress plugin. It could mean admins see something a bit like:
![Screen_Shot_2019-03-20_at_17.06.25](/uploads/83dcf5475cc7dd32c563f223fd61452b/Screen_Shot_2019-03-20_at_17.06.25.png)
One sub-page could hold the options and settings mentioned above and another might be curated to point people to plugins and resources that are WordPress-specific and enhance the experience of CiviCRM as well as its functionality.
So then... thoughts?https://lab.civicrm.org/dev/core/-/issues/1036Deprecate Tell a Friend2022-12-06T23:14:44ZAndie HuntDeprecate Tell a FriendWho tells their friends anymore? This really should be removed or deprecated.
@JonGold came up with this idea and @bgm thought it would be worth opening an issue for it.Who tells their friends anymore? This really should be removed or deprecated.
@JonGold came up with this idea and @bgm thought it would be worth opening an issue for it.https://lab.civicrm.org/dev/core/-/issues/1750View sent emails in activities2021-03-27T15:11:01ZshitijgView sent emails in activitiesOverview
----------------------------------------
As it stands currently, a CiviCRM user can send an email to a contact via a few methods. The user can also use tokens which personalise the content per contact they are sending an email t...Overview
----------------------------------------
As it stands currently, a CiviCRM user can send an email to a contact via a few methods. The user can also use tokens which personalise the content per contact they are sending an email too.
On submission, an activity is created for this. However, the activity only stores the tokens and not the actual content sent to a contact.
The behaviour for how the content of the email when we use the “send email” activity functionality is different to that from mass mailings with respect to tokens, and any used tokens aren’t replaced in the resultant stored body of the content in the activity with the actual content.
To see the content of the sent email (rather than just “token” itself) is important to users as
- They should be able to see what was sent to a contact at any given time and not just the tokens
- information might change with time i.e. the data in the field may change so the user will not know what was actually sent to the contact
Current behaviour
----------------------------------------
A mailing can be sent to the user in multiple ways in CiviCRM eg. bulk mailings, through send email activity on the contact record, inside a case, scheduled reminders, and through extensions like CiviRules.
However, when we use the send email activity form, any used tokens aren’t replaced in the resultant stored body of the content in the activity eg
![image1](/uploads/7419b37d976e1603ae2ad05d1c8619f2/image1.png)
This is happening due to an issue in the following create email activity functionality:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/Form/Task/EmailCommon.php#L467-L483
This is used:
1. When creating an activity from the contact record: This can be done by clicking on the ‘Send email’ action which triggers the form above
2. From within a case: The same form is used when creating a ‘Send email’ activity from within a case
Proposed behaviour
----------------------------------------
The created activity should store (in the content) the "resultant value" of any "tokens" with the content they were actually sent as to the recipient rather than just the {token} field name itself.
Technical implementation suggestions:
- The email activity is created before the token replacements is done here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1122.
- Token replacements are done here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1193-L1216
- Change will be to move the activity creation to just before the email is sent, after token replacements are done to somewhere like here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1227
with the following code:
$activityID = self::createEmailActivity($userID, $tokenSubject, $tokenHtml, $tokenText, $additionalDetails, $campaignId, $attachments);
We have tested this on our local and are happy to submit a core PR if the concept is approved.5.36.0https://lab.civicrm.org/dev/core/-/issues/494New permission 'Export data'2018-11-01T00:02:09ZeileenNew permission 'Export data'Per https://issues.civicrm.org/jira/browse/CRM-16326 we have a request to be able to block some users from exporting from CiviCRM. I would like to propose a new permission 'export data' which would control the display of links to export ...Per https://issues.civicrm.org/jira/browse/CRM-16326 we have a request to be able to block some users from exporting from CiviCRM. I would like to propose a new permission 'export data' which would control the display of links to export as csv & pdf from reports & to export from searcheshttps://lab.civicrm.org/dev/core/-/issues/4569Proposal: Adding confirmation messages flexibly to Form Builder2023-09-14T15:03:30ZAndreasandreas.howiller@civiservice.deProposal: Adding confirmation messages flexibly to Form BuilderOverview
----------------------------------------
This issue explains a new proposal for the "Support more workflows" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Add confirmation messages flexib...Overview
----------------------------------------
This issue explains a new proposal for the "Support more workflows" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Add confirmation messages flexibly as we know it from Drupal webforms or Caldera Forms.
Current behaviour
----------------------------------------
Currently, there is no success message at all when I submit a form - as a user, I do not receive any feedback as to whether my data has really been processed.
Proposed behaviour
----------------------------------------
There should be a message for a successful submission resp. a message for errors.
For simple use cases such as editing data in the backend, the definition of messages per form (cf. #2957) is certainly sufficient. For more complex applications, more flexibility would also make sense in view of other features on the Form Builder roadmap, e.g. displaying messages after forwarding to a multi-step form (cf. #4574) or modal forwarding. To put it short: We should do it the way webforms does:
![confirmation_webforms](/uploads/74fa65d8d384b1f6b5de1da76be0e56c/confirmation_webforms.png)
Comments
----------------------------------------
1. There should probably be a translated fallback / standard message as well.
2. In order to be able to design success messages more individually, it should be possible to include form entries in the success message. Example: Dear Frank, thank you for signing our petition. In Caldera Forms, for example, this is comfortably solved via slugs / "magic tags":
![grafik](/uploads/097c919b39a4b575a524cf4b96b4f50a/grafik.png)
Cf. "post-submit tokens" on Form Builder roadmap and #4576https://lab.civicrm.org/dev/core/-/issues/3753Proposal: Allow negative rules for ACLs2023-09-08T10:52:34ZTobias Voigttobias.voigt@civiservice.deProposal: Allow negative rules for ACLs**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - ...**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - especially if you have many (groups or sets of custom fields).
**USE CASE:**
In one of our client's system, we have many groups and many sets of custom fields. What I want to achieve is:
1. define a privileged group / role that has exclusive access to **one** set of custom fields
2. allow access to all other sets of custom fields for all users
3. prevent 'normal' users from giving themselves access to the exclusive information by adding themselves to the privileged group
Because I can only define 'positive' ACL rules, here's what I have to do:
- turn off the WP permission for custom fields for the relevant roles (to be able to define my rules via CiviCRM ACLs)
- allow access to all sets of custom fields for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each set of custom fields**
- define a rule to allow access to the restricted set of custom fields to the privileged role
Depending on the number of sets of custom fields, this can be a tedious process. Not only that - if I create a new set of custom fields at a later time, I have to remember to create a new ACL rule for that as well.
Now for the third task (preventing users from adding themselves to the privileged group). To achive this I furthermore have to:
- turn off the WP permissions for viewing and editing all contacts for the relevant roles
- allow access to all groups for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each contact group**
- define a rule to allow access to the restricted contact group only for the privileged role
Again: With about 50+ groups, that's a tedious task. And again: I have to remember to create a new ACL rule each time I add a new group.
All in all I could end up with a multitude of rules (in our case 70+) that are really hard to maintain.
**PROPOSAL:**
This task could be so much easier, if it was possible to define 'negative' ACL rules. If this was possible, I could:
- turn off the relevant WP permissions
- allow access to all sets of custom fields for everyone (1 rule)
- allow access to all contact groups for everyone (1 rule)
- disallow access to the restricted set of custom fields for everyone (1 rule)
- disallow access to the restricted contact group for everyone (1 rule)
- allow access to the restricted set of custom fields for the privileged role (1 rule)
- allow access to the restricted contact group for the privileged role (1 rule)
As is implied above, **there would have to be some form of priorisation** of rules to make this work.
This way I would end up with only 6 rules and would not have to remember to create new rules whenever I create a new set of custom fields or a new contact group.5.64.0https://lab.civicrm.org/dev/user-interface/-/issues/46Modernise ship-with-civi theme2023-09-20T15:55:57ZeileenModernise ship-with-civi themeI've opened this issue to see if we can agree on a way to improve the theme that ships with core (or to ship an additional theme with core) without the discussion spinning out into the technical sprawl that always seems to paralyse us on...I've opened this issue to see if we can agree on a way to improve the theme that ships with core (or to ship an additional theme with core) without the discussion spinning out into the technical sprawl that always seems to paralyse us on this issue...
**Problem statement**
CiviCRM ships with a theme looks dated and is off-putting to new adopters- some specific criticisms
- Colours are …. Beige. Current fashion would seem to be more white space (also drab in bootstrap)
- Button styling seems dated
- Some people seem to prefer side tabs - not sure if this is consensus
Goal of issue/discussion
- Find some achievable improvements
- Don’t get bogged down on solving everything
Potential solutions
- Improve the Greenwich theme - possibly as a paralell theme - addressing the most egregious issues (e.g just swapping colours / using more white makes it look more modern)
- Add an existing theme to core (Shoreditch, Aah, Finsbury park, Christian’s theme). Note that if we do this
1) it will mean that the theme becomes part of core codebase & would be maintained as such, with a priority place on maintainability and ensuring not too much css is downloaded (which might not always be in line with the designer’s vision).
2) bringing an existing theme into core would require the mainintainer agreeing to their theme being forked into a core extension & the core extension being maintained according to core maintenance priorities & principles. This may not be something current theme maintainers want as some design elements are likely to be sacrificed in the pursuit of maintainability / compatibility.
2) Anything that ships in core must work on all CMS and have acceptable page load speed for anonymouse users.
- Build up a minimal theme - ie what is the min theming we need to do to make it ‘load’ & move the rest of the css to greenwich (this is assuming a minimal theme would be better….)
Note that this ticket https://lab.civicrm.org/dev/user-interface/-/issues/33 covers previously discussion. Those discussions focussed on making it easier for themers to theme CiviCRM whereas the focus on this is what can we do to make the CiviCRM that ships with core look better.https://lab.civicrm.org/dev/core/-/issues/2998Epic: Re-implement CiviCRM Standalone (CMS-less CiviCRM)2024-02-09T14:12:15ZbgmEpic: Re-implement CiviCRM Standalone (CMS-less CiviCRM)Follow-up to dev/core#1153, and [more context in this wiki page](https://lab.civicrm.org/dev/core/-/wikis/standalone), this is an epic to track the main tasks to implement CiviCRM Standalone.
- [x] Base classes (Hook, System, Permission...Follow-up to dev/core#1153, and [more context in this wiki page](https://lab.civicrm.org/dev/core/-/wikis/standalone), this is an epic to track the main tasks to implement CiviCRM Standalone.
- [x] Base classes (Hook, System, Permission and css/tpl so that Standalone can boot / proof-of-concept [PR22227](https://github.com/civicrm/civicrm-core/pull/22227)
- [x] Basic composer project to handle the code-case (see: https://github.com/civicrm/civicrm-standalone)
- [x] Composer template project that follows best-practices (see: https://github.com/civicrm/civicrm-core/pull/26771)
- [x] Implement a breadcrumb (see: https://github.com/civicrm/civicrm-core/pull/26782)
- [x] Login page (standaloneusers ext now included in core)
- [x] dev/core#4053 User management and permissions
- [x] initial user roles dev/core#4466
- [x] Password reset by email [PR28505](https://github.com/civicrm/civicrm-core/pull/28505), [PR27681](https://github.com/civicrm/civicrm-core/pull/28505)
- [x] Clean URLs
- [x] [Language switcher](https://civicrm.org/extensions/language-switcher) - language links are missing `lcMessages=xx_YY` and session change is not sticky. See #4425 and [PR#27040](https://github.com/civicrm/civicrm-core/pull/27040)
- [x] GenCode
- [x] Installer (using 'civicrm-setup')
- [x] Buildkit (mostly, requires `cv` support, see: https://github.com/civicrm/civicrm-buildkit/pull/662)
- [x] cv (workaround: `CIVICRM_SETTINGS="/var/www/standalone/data/civicrm.settings.php" cv sql:cli`)
- [x] Backend themes (test [known themes](https://civicrm.org/extensions?field_extension_civi_use_target_id=356))
- [x] Releaser support (create tar.gz for official downloads) - https://github.com/civicrm/civicrm-core/pull/27104
- [x] Demo site (https://github.com/civicrm/civicrm-buildkit/pull/794)
- [X] Installation documentation https://docs.civicrm.org/installation/en/latest/standalone/
- [x] Getting started dashlet - alert.civicrm.org needs to be updated to understand "uf=Standalone" since it currently gives error 500, e.g. `https://alert.civicrm.org/welcome?prot=1&ver=5.46.alpha1&uf=Standalone&sid=blah&lang=en_US&co=`
- [x] https://lab.civicrm.org/infra/community-messages/-/merge_requests/2
- [x] High-level error handler. https://github.com/civicrm/civicrm-core/pull/26965
- [x] How to treat cms.root. The rest of the work so far is treating "standalone" as if it were a cms, so it should probably return _something_ for it.
- [x] Nicer Role/Permission UI, permission for adding users
Known minor bugs:
- [x] On the `/civicrm/admin` page, the links are missing the leading `/`
- [x] Because CRM/Utils/System/Standalone.php automatically sets `userID = 1`, that CID is the default org record, so some public forms such as Event Registrations, behave incorrectly. Will be fixed when we implement users.
- [x] Might be a local issue but I [DaveD] get the old files system status warning. There's an open ticket somewhere about this happening for drupal 8 sometimes so might be similar.
Nice to haves, but not release-critical:
- [ ] Front-end theme?https://lab.civicrm.org/dev/core/-/issues/1613updating misleading labels on buttons to confirmation pages2023-06-20T23:09:15Zyosefromanoupdating misleading labels on buttons to confirmation pagesOn contribution forms, the button leading to the confirmation page (if enabled) says 'confirm payment' which in many cases makes the user think that clicking the button submits the contribution.
On event forms, the button leading to th...On contribution forms, the button leading to the confirmation page (if enabled) says 'confirm payment' which in many cases makes the user think that clicking the button submits the contribution.
On event forms, the button leading to the confirmation page (if enabled) says 'continue' which again in many cases is misconstrued to mean 'continue and complete'
I get constant feedback from at least 50 different sites that their constituents are leaving the form before submitting it because they assume it was submitted leading to loss of revenue.
From looking at all shopping websites the industry standard with buttons leading to confirmation pages seems to be to use the word 'review'
The proposed solution in both cases is that the button label should simply say 'Review'.5.25.0https://lab.civicrm.org/dev/core/-/issues/663Deprecate ARCHIVE format for CiviCRM Database Logging2021-05-11T16:45:30ZxurizaemonDeprecate ARCHIVE format for CiviCRM Database LoggingThe ARCHIVE format seemed like a good idea at the time (it takes less space), but my sense is that very few organisations actively involved with CiviCRM choose to use ARCHIVE. I believe the experience of most has been that ARCHIVE storag...The ARCHIVE format seemed like a good idea at the time (it takes less space), but my sense is that very few organisations actively involved with CiviCRM choose to use ARCHIVE. I believe the experience of most has been that ARCHIVE storage format is unreliable and the cause of various issues affecting site performance, backup reliability and other issues.
I propose that we switch the default storage format for sites activating Database Logging to the current default for that site's database.
Alternative approach might be to ship [nz.co.fuzion.innodbtriggers](https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers) activated by default on new installs (but this feels like it could add more complexity than just removing the ARCHIVE statements on new logging activation).
> "The INNODB format is arguablly a better format for CiviCRM logging. Although INNODB tables take more space, they can be queried much more effectively, which is useful when you want to consult the logs. Consulting the change log for ARCHIVE tables is phohibitivley slow once your logging has been running a while." - [Fuzion InnoDB Triggers extension README](https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers).
IMO this could be a "missing stair" situation - a known issue to those familiar with CiviCRM, but a gotcha for those unfamiliar, and therefore something which can go unfixed for a long time and has impact primarily on those new to the community/userbase.
Of particular consideration is the risk to sites who would be impacted by InnoDB using more diskspace - we don't want to ship a change which triggers disk outages as ARCHIVE tables are unzipped. I propose that we not do that.
I'm interested to hear from CiviCRM community members who do prefer the ARCHIVE format?
Related:
* https://github.com/civicrm/civicrm-sysadmin-guide/pull/142
* https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers
* https://civicrm.stackexchange.com/questions/2137/what-causes-periodic-database-errors-while-using-logging-and-what-should-i-do-a
* https://civicrm.stackexchange.com/questions/17733/db-error-unknown-error-when-adding-custom-field/17743#17743
* https://civicrm.stackexchange.com/questions/17770/archive-not-enabled-by-default-on-mariadb-10-1
* https://civicrm.stackexchange.com/questions/23075/any-other-way-to-disable-db-logging-civicrm-4-6x
* https://civicrm.stackexchange.com/questions/25318/large-civicrm-logshttps://lab.civicrm.org/dev/core/-/issues/3782Don't prevent contact with Cancelled membership from signing up online2023-01-02T17:47:01Zmattwiremjw@mjwconsult.co.ukDon't prevent contact with Cancelled membership from signing up onlineContribution page prevents signing up for a membership if the matched contact has an existing cancelled membership of the same type.
I don't really understand why https://github.com/civicrm/civicrm-core/pull/3531 ever got merged given t...Contribution page prevents signing up for a membership if the matched contact has an existing cancelled membership of the same type.
I don't really understand why https://github.com/civicrm/civicrm-core/pull/3531 ever got merged given that it seems no-one was in favour of restricting memberships in this way: https://issues.civicrm.org/jira/browse/CRM-14645
A restriction such as this could easily be put in place via the `validateForm` hook for anyone who actually needs it and it seems a pretty obscure restriction to have hardcoded in core.5.56.0https://lab.civicrm.org/dev/financial/-/issues/118Proposal - move source & received date to near the top on ContributionView form2020-08-31T02:50:30ZeileenProposal - move source & received date to near the top on ContributionView formI realise that any UI changes generally fall apart on discussion / scope creep so I want to keep this proposal very specific & I'll either procede with it or not based on up & down votes - the Proposal is to move the Source & Received da...I realise that any UI changes generally fall apart on discussion / scope creep so I want to keep this proposal very specific & I'll either procede with it or not based on up & down votes - the Proposal is to move the Source & Received date fields to the top on the contribution view screen
**Proposed location**
(note moving the payment summary into where Total Amount sites is is in the screenshot out of scope for this proposal)
![Screen_Shot_2020-02-15_at_2.45.54_PM](/uploads/8d5c9f99236ba679e7c550986dc764c1/Screen_Shot_2020-02-15_at_2.45.54_PM.png)
**Current location**
(note the double Total Amount is a bug which I will look at once https://github.com/civicrm/civicrm-core/pull/16531 is resolved as the technique will be part of the solution if agreed)
![Screen_Shot_2020-02-15_at_2.26.31_PM](/uploads/14d9e729c34efe642d66bffa26568b68/Screen_Shot_2020-02-15_at_2.26.31_PM.png)
Rationale - I think the 'what & when' about a contribution is key at-a-glance information & it should be near the top (possibly above financial type too). The other detail is increasingly weedsy payment information - & I feel further down makes sensehttps://lab.civicrm.org/dev/core/-/issues/830Proposal - add cancel_reason field to civicrm_contribution_recur table2020-07-13T00:08:49ZeileenProposal - add cancel_reason field to civicrm_contribution_recur tableWe have a request to add a field cancel_reason to the civicrm_contribution_recur table.
The main reason to consider putting this in core (as opposed to a custom field) is that it would provide consistency with the civicrm_contribution ...We have a request to add a field cancel_reason to the civicrm_contribution_recur table.
The main reason to consider putting this in core (as opposed to a custom field) is that it would provide consistency with the civicrm_contribution table which has cancel_date & cancel_reason (the latter being toggled for visibility based on the former).
Associated cleanup
- I think it's kind of a condition of adding any UI feature / functionality/ new field to core that some sort of tangental cleanup is also done - I think probably the related area that could most do with some love is to add the field to the contribution search & add unit test coverage for the recurring contribution fields - they currently are not covered by any searches.
Review
- If we do this I will trade review with someone - probably Matt Wire as I don't assume someone will 'just review it'https://lab.civicrm.org/dev/core/-/issues/720Performance change approved - remove mode & median slow queries2019-02-19T04:53:15ZeileenPerformance change approved - remove mode & median slow queriesUpdate - simply removing per decision by @colemanw below....
---------------------------------------------------------------
Original
----------------------------------------------------------------
The calculations done for the summary...Update - simply removing per decision by @colemanw below....
---------------------------------------------------------------
Original
----------------------------------------------------------------
The calculations done for the summary statistics on the contribution search is currently the biggest point of slowness we are facing. The following stats are generated:
'count' (number completed)
'amount' (total amount of completed)
'avg' (average amount of completed)
'mode' (most common value of completed)
'median' (median value of complete)
'cancel_amount' (total of cancelled)
'cancel_count' (number cancelled)
'cancel_avg' (average amount of cancelled)
These are then grouped by currency.
Of these the count and total amount are highly useful whereas the usefulness of mode & median are more niche.
On the other hand it is possible to fix up MOST of these queries to perform well. Mode and median are pretty much impossible to make performant on a large result set, and are actually the main reason our users have to do carefully constrained queries that don't return more than around 50k of results.
Let's assume we do a query that returns 50,000 results and the criteria is the payment_instrument_id then ideally that field will be used as the index on the query and we get the main query returned pretty quickly.
However, in order to do a median query it is necessary to order the results by total_amount. We can't use both indexes, and we can't add combined indexes for every combination of total_amount & possible criteria so we are one way or another going to be either
- using the total_amount index to sort & doing an unindexed filter - on our whole DB....
- using the index to filter & doing an unindexed sort on 50k rows
- using a merged index (these take time to compile)
Some queries are possible to rewrite - I recently got the annual query down from 6 seconds to .02 seconds but the median query just isn't every going to scale well.
Which leaves us with 'how can we help sites that with users are not happy twiddling their thumbs while the median is calculated'.
There are a few options IMHO
1) just remove median & mean - no-one (by which I mean me) cares about them anyway
2) add a setting that allows a site to specify which contribution stats they want calculated
3) only calculate median & mean if the total number of rows is < 1000
4) add a hook to permit the queries that run to be altered
Of these both 1 & 3 are imposing change on people who might not want change.
Adding a setting seems like a hack. In general adding settings to tweak core behaviour for a different use case/ preferences is almost always a hack - although the use case 'I have a big database' is perhaps a bit more generic than the 'I'd like this page/search bar / widget to behave differently & the least hassle on me is to add a setting'
I do think, however, that 4 is probably the least hacky / most sensible and it will 'gracefully retire itself' when we finally get a better search screen that doesn't use the query object.
I think it would look like
```
hookAlterQuerySummary($entity, $context, &$callbacks);
```
(only Contribution is relevant at the moment but passing entity seems to make sense)
We would have to break out the existing queries to their own fns & then we'd get
$callbacks = [
'CRM_Contact_BAO_Query::getBasicStats',
'CRM_Contact_BAO_Query::getMedian',
'CRM_Contact_BAO_Query::getMean',
'CRM_Contact_BAO_Query::getCancelStats'
]
There would then be a call like
CRM_Contact_BAO_Query::getBasicStats($rowStats, $whereClause, $fromClause)
And $rowStats would be altered by the function adding values & labels so the tpl could iterate through them
Longer term - I would argue the slow stats should probably be ADDED rather than REMOVED by extension as I think shipping something that makes hard-to-justify performance trade-offs is a big call5.12.0https://lab.civicrm.org/dev/core/-/issues/4808Proposal: Phase out public profile fields and profile listings2023-12-06T22:08:58ZbgmProposal: Phase out public profile fields and profile listingsNow that SearchKit provides this functionality, we should consider deprecating "public profile fields" and profile listings. They are a recurrent source of confusion and a bad configuration can lead to a data leak (I stumble on them regu...Now that SearchKit provides this functionality, we should consider deprecating "public profile fields" and profile listings. They are a recurrent source of confusion and a bad configuration can lead to a data leak (I stumble on them regularly, with the help of the [symbiotic extension](https://civicrm.org/extensions/symbiotic).
I think we should:
- [ ] Add a feature flag (a hidden setting?) that hides
- ~~On Profiles, the option "Standalone Form or Directory"~~ (edit: I guess this might be needed for profile/edit of users with a checksum?)
- On Profile Fields: hide the visibility options, set them by default to "User and Admin only"
- [ ] Remove the feature from the Admin documentation
- [ ] Begin changing the interface to warn that we will be removing this feature, and that they can opt-in to that change right now
- [ ] Set a date for complete removal (or if someone really insists on keeping this feature, help them create an extension for it)https://lab.civicrm.org/dev/user-interface/-/issues/54Move Contact Delete under the Actions menu2023-08-03T12:46:53ZbgmMove Contact Delete under the Actions menuThe "Delete Contact" takes a lot of central space on the View Contact screen, for something that should not be used so often.
![image](/uploads/736e0a017da5843c05c516866ec33118/image.png)
Proposed change:
![image](/uploads/1628e25c854...The "Delete Contact" takes a lot of central space on the View Contact screen, for something that should not be used so often.
![image](/uploads/736e0a017da5843c05c516866ec33118/image.png)
Proposed change:
![image](/uploads/1628e25c85495a510c48b3ab7a3641db/image.png)
Related (closed) PR: https://github.com/civicrm/civicrm-core/pull/26903https://lab.civicrm.org/dev/core/-/issues/4154Number field input validation does not respect decimal separator setting2024-03-20T10:36:25ZnoahNumber field input validation does not respect decimal separator settingOverview
----------------------------------------
This issue has to do with "number" (float) custom fields on some edit forms. When you enter a number containing any character other than a digit or a period (full stop) into such a field,...Overview
----------------------------------------
This issue has to do with "number" (float) custom fields on some edit forms. When you enter a number containing any character other than a digit or a period (full stop) into such a field, validation fails. This happens even if the offending character has been set as the decimal separator in Civi's localization settings.
Reproduction steps
----------------------------------------
1. Under Administer > Localization > Languages, Currency, Locations, set "Decimal Delimiter" to "," (comma).
1. Create a custom field extending Activities. Data type: Number.
1. Add a new activity. In the number field, enter a number that includes a comma, such as "123,45" (one hundred twenty three and forty-five one-hundredths).
1. Press Save.
Current behaviour
----------------------------------------
Validation fails with the error message "[Custom Field Label] must be a number (with or without decimal point)."
Expected behaviour
----------------------------------------
The form should save the entered amount as (float) one hundred twenty three and forty-five one-hundredths.
Environment information
----------------------------------------
CiviCRM 5.60 (current master HEAD).
Comments
----------------------------------------
Somewhat entangled with #41525.68.0https://lab.civicrm.org/dev/core/-/issues/3835Proposal: Deprecate profile standalone listing mode2023-11-30T17:03:40ZJonGoldProposal: Deprecate profile standalone listing modeProfile standalone listing code is deeply entangled with the query BAOs, and produces weird and wonderful bugs like #3834.
I don't think they're widely used in modern CiviCRM, they seem to have been a stopgap before Views integration, a...Profile standalone listing code is deeply entangled with the query BAOs, and produces weird and wonderful bugs like #3834.
I don't think they're widely used in modern CiviCRM, they seem to have been a stopgap before Views integration, and later for non-Drupal users to get a Views-esque experience. But Search Kit has effectively replaced them - they have feature parity and then some.
I think we can improve the query code if we no longer needed to worry about standalone listing mode.
Proposal:
* Remove the ability to create standalone listings on new installations of CiviCRM.
* Create a check for profiles using standalone listing mode, warning admins if they use it.
We can deprecate this over a long period of time, so the impact should be gentle.
If this proposal is approved, we may also want to consider a function that converts profile listings to SK searches. This will have added utility as we deprecate other uses of profiles (e.g. once SK replaces Advanced Search, Search Profiles will go away).https://lab.civicrm.org/dev/core/-/issues/2640User experience improvement, hide by default the Latitude and Longitude fiel...2023-08-23T00:28:55Zjustinfreeman (Agileware)User experience improvement, hide by default the Latitude and Longitude fields, users can enable display if neededWe have found that users are somewhat confused by the default display of the Latitude and Longitude fields in the Address section for Contacts. This is a proposal to change the default so that the Latitude and Longitude fields are not di...We have found that users are somewhat confused by the default display of the Latitude and Longitude fields in the Address section for Contacts. This is a proposal to change the default so that the Latitude and Longitude fields are not displayed by default. This would affect both new sites and existing sites that rely on the default settings and require an upgrade message to notify existing sites of this change.
The change is to de-select the Latitude and Longitude fields in the Address Settings. CiviCRM > Administer CiviCRM > Address Settings
![Screenshot_20210608_091407](/uploads/ca7ad12a7aa0e9472d92c40b41b6f485/Screenshot_20210608_091407.png)
This change was initially discussed in MM and support indicated, see https://chat.civicrm.org/civicrm/channels/product-roadmap/pzm9gqjy4jdeznennqi6kuhceo
Agileware will provide a PR at some stage.
Agileware Ref: CIVIUX-1415.66.0https://lab.civicrm.org/dev/core/-/issues/2243Add created_date column to the civicrm_note table2021-03-28T16:44:34ZjasonmAdd created_date column to the civicrm_note tableOverview
----------------------------------------
After merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It wou...Overview
----------------------------------------
After merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It would be helpful for note records to store both the created date and the last modified date and to display both dates in the notes list view at /civicrm/contact/view?reset=1&cid=xxxxxx
Example use-case
----------------------------------------
The user wants to see the date that a note was created in addition to when a note was last modified.
Current behaviour
----------------------------------------
Currently the civicrm_note table has only a modified_date field so the date a note is created is lost upon any update.
Proposed behaviour
----------------------------------------
Add a created_date column to the civicrm_note table and display both created and modified dates at /civicrm/contact/view?reset=1&cid=xxxxxx
![screenshot-a](/uploads/99cabcdde44fa725841c2d5de5afd28a/screenshot-a.png)
![screenshot-b](/uploads/003327183320ec3af790840cbe835393/screenshot-b.png)
![screenshot-c](/uploads/d8ecdc89bb06f23037df82ea81e4974e/screenshot-c.png)5.37.0