Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-02-27T23:34:43Zhttps://lab.civicrm.org/dev/user-interface/-/issues/33Theming meta issue2022-02-27T23:34:43ZeileenTheming meta issueI've created this issue so we can have somewhere to put the link to the theming presentation that took place this week (once it's available).
I would encourage people to link to other issues or repositories discussed as part of do-ocrac...I've created this issue so we can have somewhere to put the link to the theming presentation that took place this week (once it's available).
I would encourage people to link to other issues or repositories discussed as part of do-ocracy week from here too.https://lab.civicrm.org/dev/core/-/issues/5056Theming of remote oEmbed / iFrame2024-03-07T13:38:52ZJoeMurrayTheming of remote oEmbed / iFrameWe are adding the ability to publish eEmbed / iFrame functionality from CiviCRM to remote sites. (https://github.com/totten/civicrm-core/blob/master-oembed/ext/oembed/README.md#issues--todos). The backend CiviCRM site is a provider or pu...We are adding the ability to publish eEmbed / iFrame functionality from CiviCRM to remote sites. (https://github.com/totten/civicrm-core/blob/master-oembed/ext/oembed/README.md#issues--todos). The backend CiviCRM site is a provider or publisher of content, typically forms. We're going to call front end sites that consume this content consumer sites.
Two prototypical use cases are:
1. An organization uses a Standalone backend CiviCRM instance to publish public facing pages on their public WordPress site (contribution page, newsletter subscription page, event registration pages) which is the only consumer site.
2. An organization publishes some content that it encourages aligned partners to display on their sites, e.g. a FormBuilder based petition that needs to appear on many consumer sites with different themes including colour schemes, fonts, etc.
In both cases there is a need to make the content inside the oEmbed/iFrame look okay or even good on the consumer sites.
There is a need to develop approaches to theming the content that will be presently remotely on consumer sites.
In case 1, it may be reasonable for the organization to create a theme on the backend publisher site that matches the front end theme. However, the backend CiviCRM publisher may be a locked down site like Spark which does not provide this level of access.
As of March 1, 2024 it is possible on backend site to select a site-wide theme, and for parameters in the oEmbed/iFrame requests to include width and height for the window of content.
@kcristiano has had success in using css on a consumer site to theme the content inside an iFrame (target the selectors).
Many sites that publish pages in iFrames for remote consumption allow small theming choices to be made, eg foreground and background colour, etc.
As of March 1, 2024, selected content on a CiviCRM site can expose urls for oEmbed and iFrame references to that content.
It might be desirable to have a consumer choose to make some small theming adjustments to the CiviCRM content that will be rendered on their site, adjusting the url for the oEmbed or iFrame. The url could get key-value pairs for the theming adjustments or perhaps they could be stored in a record in a database or used to create a css file on disk that would be requested with a single key-value pair in the url.
What are the considerations and desiderata for providing a simple usable approach to end users to get an iFrame reference that provides some theming of the content? For example, what is a reasonable set of end user oriented settings that are not overwhelming that could be made available? Foreground colour, background colour, font, etc?
Should there be a different set that would make available a fairly full set of tags for CiviCRM forms, including h1, h2, etc all the way to styling of selects, buttons, checkboxes, etc.?JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/4357Timezone with Drupal 9, CiviCRM entity and Views2023-12-23T00:55:25Z5knotsTimezone with Drupal 9, CiviCRM entity and ViewsOverview
----------------------------------------
We are working with grants, where fields like "money transferred" exist. This field is stored in the database as a "date-only" value (screenshot). However, Drupal interprets the date as a...Overview
----------------------------------------
We are working with grants, where fields like "money transferred" exist. This field is stored in the database as a "date-only" value (screenshot). However, Drupal interprets the date as a datetime field and, presumably, sets the time to 12 noon, but a day before. This leads to inconsistent dates in Drupal Views outputs. Is there a known workaround to avoid this issue? Currently, I have set a fixed 12-hour timezone difference for the View, which works but is not an ideal solution.
Reproduction steps
----------------------------------------
1. Install civicrm entity and enable grants
1. go to Drupal Views and create a new view based on grants.
1. include fields like 'money transferred'
Current behaviour
----------------------------------------
Drupal interprets the date as a **datetime** field.
Both attached screenshots are from the same entry.
![Bildschirmfoto_2023-06-13_um_14.41.49](/uploads/6b7df46f1fdd9354238c4e4e90ce0dec/Bildschirmfoto_2023-06-13_um_14.41.49.png)
![Bildschirmfoto_2023-06-13_um_14.43.32](/uploads/e324ce91d7fe2a48a0ce84c4bb580589/Bildschirmfoto_2023-06-13_um_14.43.32.png)
Expected behaviour
----------------------------------------
Drupal interprets the date as a **date** field.
Environment information
----------------------------------------
D9.5, CiviCRM 5.62, civicrm_entity /latesthttps://lab.civicrm.org/dev/financial/-/issues/128To be Autorenew or not to be - that's the question2023-11-23T07:19:54ZKarinGTo be Autorenew or not to be - that's the question**Purpose of this Lab issue is to **
1. document the various places/switches in Core with references to Membership Autorenew
2. review them and try reach consensus on how these switches should work under various conditions, like e.g.
*...**Purpose of this Lab issue is to **
1. document the various places/switches in Core with references to Membership Autorenew
2. review them and try reach consensus on how these switches should work under various conditions, like e.g.
* [ ] a) what should happen if a contribution in the recurring contribution series linked to the Membership failed?
* [ ] b) what should happen if there is a conflict -> Membership not configured to renew Automatically, but there are line items with references to that Membership?
* [ ] c) etc.
3. propose tangible small iterative steps forwards
@seamuslee @mattwire @justinfreeman @eileen
I'm going to start with 1!https://lab.civicrm.org/dev/core/-/issues/4223To edit price sets CiviContribute access needed2023-04-12T07:25:37ZMariaVTo edit price sets CiviContribute access neededOverview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or...Overview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or created because of the financial type.
Reproduction steps
----------------------------------------
1. Create price set for Events (with a user without CiviContribute access)
2. Create price field (radio buttons)
3. Add options to this price field
4. Fill all needed information
5. Save
6. Error "financial type is mandatory"
Current behaviour
----------------------------------------
When I open a price set option it shows me this:
![image](/uploads/f5b1e1b6648bb6beb30cf36b3ab2fe7a/image.png)
(Zuwendungsart = financial type)
With administrator this:
![image](/uploads/b6fc64b239dad54bbf4ba68c72434241/image.png)
If I give "CiviContribute access" it works.
Expected behaviour
----------------------------------------
When CiviEvent access is given, users are allowed to create price sets.
Environment information
----------------------------------------
* __CiviCRM:__ _5.58.1
* __CMS:__ _Drupal 7https://lab.civicrm.org/dev/core/-/issues/4776Todo: Look at whether these test fails mean anything2023-11-14T16:38:47ZDaveDTodo: Look at whether these test fails mean anythingSomewhere in their flow, they call CRM_Core_Form::getAuthenticatedCheckSumContactID and it calls CRM_Core_Form::getRequestedContactID which returns null. Should it be null or the correct contact id?
This maybe qualifies as a regression ...Somewhere in their flow, they call CRM_Core_Form::getAuthenticatedCheckSumContactID and it calls CRM_Core_Form::getRequestedContactID which returns null. Should it be null or the correct contact id?
This maybe qualifies as a regression but at the moment I don't have a specific bug. It came up in the context of https://github.com/civicrm/civicrm-core/pull/28128 where they all fail if validateAuthenticatedCheckSumContactID() is expecting not null.
api_v3_ContributionPageTest.testValidate
api_v3_ContributionPageTest.testValidatePost
api_v3_ContributionPageTest.testValidateOutputOnMissingRecurFields
CRM_Contribute_Form_Contribution_ConfirmTest.testPayNowPayment
CRM_Contribute_Form_Contribution_ConfirmTest.testSeparatePaymentConfirm
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunction
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunctionOptionalYes
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunctionOptionalNo
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunctionNotAvailable
CRM_Contribute_Form_Contribution_MainTest.testExpiredPriceSet
CRM_Contribute_Form_ContributionTest.testContributionBasePreProcess
CRM_Core_FormTest.testGetAuthenticatedUser
CRM_Event_Form_Registration_ConfirmTest.testSubmit
CRM_Event_Form_Registration_ConfirmTest.testWaitlistRegistrationContactIDParam
CRM_Event_Form_Registration_ConfirmTest.testTaxMultipleParticipant
CRM_Event_Form_Registration_ConfirmTest.testMailMultipleParticipant
CRM_Event_Form_Registration_ConfirmTest.testOnlineRegNoPrice
CRM_Event_Form_Registration_ConfirmTest.testSubmitNonPrimaryEmail
CRM_Event_Form_Registration_ConfirmTest.testRegistrationWithoutCiviContributeEnabled
CRM_Event_Form_Registration_ConfirmTest.testPaidSubmit with data set #0
CRM_Event_Form_Registration_ConfirmTest.testPaidSubmit with data set #1
CRM_Event_Form_ParticipantTest.testTransferParticipantRegistration
CRM_Event_Form_SelfSvcTransferTest.testCancel
CRM_Event_Form_Registration_ConfirmTest.testNoteSubmissionhttps://lab.civicrm.org/dev/core/-/issues/4395Token support to allow us to migrate sort_name, display_name, address formats...2023-06-28T07:10:08ZeileenToken support to allow us to migrate sort_name, display_name, address formats to tokensWe have a goal to get sort_name, display_name and address formats to resolve using the standard token system, at the same time as the greetings are resolved.
Unfortunately there are some things they support at the moment that our tokens...We have a goal to get sort_name, display_name and address formats to resolve using the standard token system, at the same time as the greetings are resolved.
Unfortunately there are some things they support at the moment that our tokens don't. Our tokens DO support the default filter
`{contact.first_name|default:"donor"}`
and they support the magic space - ie
`{contact.first_name}{ }{contact.last_name}`
which resolves a space in the above, but not if there is no last name.
However, in sort name there is a variant on the magic space we don't currently support in tokens - - ie
`{contact.last_name}{, }{contact.first_name}`
The regex that supports that actually removes the whole `{}` contents if the following tag is empty or renders the contents otherwise.
This is pretty hard to make compatible with smarty :-(, which is a requirement to standardise. So ideally we would
1) make the magic syntax support know usages (within reason) which so far are the magic space, the magic comma and this variant
`{contact.first_name}{ ~ }{contact.nick_name}{ ~ }{contact.last_name}`
2) add a system-check to highlight notify using variations of the magic syntax other than the 3 on our radar that they may not work in future upgrades if we don't add support & direct them to this ticket to comment & explain the use case
3) depending on the variations that come out of 2 add 'micro-conditional support'
Note micro-conditionals was an idea @totten came up with when we were spit-balling this - I've pasted his thoughts below
---------------------------------------------------------------------------------------------------------------------
micro-conditionals: special tokens that conditionally display a handful of symbols
```
---------
{contact.first_name} {contact.last_name} { ~ } {contact.nick_name}
{contact.last_name}{ }{contact.first_name}
{contact.last_name}{, }{contact.first_name}
{contact.first_name}{ (}{contact.nick_name}{) }{contact.last_name}
Dear {contact.first_name}{?friend},
----------
{contact.first_name contact.last_name " ~ " contact.nick_name}
{contact.last_name " " contact.first_name}
{contact.last_name ", " contact.first_name}
{contact.first_name " (" contact.nick_name ") " contact.last_name}
Dear {contact.first_name ?friend},
----------
{{{contact.first_name contact.last_name ~ contact.nick_name}}}
{{{contact.last_name contact.first_name}}}
{{{contact.last_name, contact.first_name}}}
{{{contact.first_name (contact.nick_name) contact.last_name}}}
Dear {{{contact.first_name??"friend"}}},
-------------
```
Also note - first draft of appropriate test https://github.com/civicrm/civicrm-core/pull/26637/files#diff-a5d237ba4e392d0e8ad764a535315f0b1101cc5ca61c39b4e572de42f5c6b4bchttps://lab.civicrm.org/dev/core/-/issues/4214Too many CiviCRM custom fields breaks logging resulting in mysterious errors2023-04-05T14:36:26Zluke.stewartToo many CiviCRM custom fields breaks logging resulting in mysterious errorsOverview
----------------------------------------
If for some strange reason you decide to create **_a lot_** of custom fields - and use detailed logging you can break stuff rather badly without getting a nice warning.
Reproduction ...Overview
----------------------------------------
If for some strange reason you decide to create **_a lot_** of custom fields - and use detailed logging you can break stuff rather badly without getting a nice warning.
Reproduction steps
----------------------------------------
1. Turn on detailed logging
1. Create yourself a custom field group - or use one you've prepared earlier.
1. Add a lot of text fields with max length. This probably depends on database settings - for mariadb what your database innodb_page_size variable is set to.
1. At some point you will be able to add new fields to the custom group - but the row size will be exceeded when these fields are added to the log_custom_group_value_thing_table.
1. From this point on any operation attempting to write data into that table will result in errors when Detail logging is turned on. However due to the joys of detailed logging it will say something like field X doesn't exist - however it does - but field Y will exist on that table but not on the log_table.
1. You will possibly notice a small error message showing when turning detailed logging on.
Current behaviour
----------------------------------------
You get errors like this when turning
```
[nativecode=1118 ** Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs]
```
Expected behaviour
----------------------------------------
You should probably not be able to create custom fields after a certain point. however perhaps more to the point - if there is an error turning detailed logging on and it relates to a schema mismatch then perhaps it would be better to - turn the detailed logging back off - return a Computer says no message - along with a list of log tables that don't match what they should.https://lab.civicrm.org/dev/core/-/issues/4251Track Contact `image_URL` files in the `civicrm_file` table2024-01-02T21:02:33ZcolemanwTrack Contact `image_URL` files in the `civicrm_file` table# History
**Note: CiviCRM is a large, old project with many contributors, which makes "big picture" perspectives cumbersome to gather. Often a contributor simply wants to fix a bug or add a small feature, not dive into decades-long hist...# History
**Note: CiviCRM is a large, old project with many contributors, which makes "big picture" perspectives cumbersome to gather. Often a contributor simply wants to fix a bug or add a small feature, not dive into decades-long history and contemplate massive refactoring. The story of the `civicrm_contact.image_URL` field is a microcosm of the complicated world of CiviCRM.**
- The `civicrm_contact.image_URL` field (added v1.1) predates the `civicrm_file` table (added v1.5), which may explain why it was originally designed as a simple textfield with no file-management. It is a simple varchar and can store the url to any image file on the web.
- Originally, the UI allowed contact image files to be uploaded to a publicly-readable directory on the webserver, and `image_URL` stored an absolute url to that file.
- In 2014, [security hardening](https://issues.civicrm.org/jira/browse/CRM-14499) led to the addition of an `.htaccess` rule which blocked the contents of that directory from public visibility.
- This accidentally broke contact images, leading to [a rushed fix](https://github.com/civicrm/civicrm-core/pull/3058) which created `CRM_Contact_Page_ImageFile` at `civicrm/contact/imagefile`. This path allows open access to all contact images, but not other files, by querying `civicrm_contact.image_URL` for a matching filename before outputting the contents. An upgrade script rewrote all local `image_URL` fields to point to this path, using an absolute URL. This solution works but is very slow on big databases due to the unindexed query.
- During this rushed fix, it doesn't appear that consideration was given to html escaping of `&` characters. The default behavior of `CRM_Utils_System::url` is to escape `&` to `&` which is (IMHO) a bad default and certainly a poor choice for storing url strings in the database, but it was the default and no one changed it, and then Tim inadvertently cemented it with 065034510d48b722844b2007f8016ea644bd0cbd so now in order to safely read the urls you must pass them through the aptly-named `CRM_Utils_String::unstupifyUrl()` function.
- In 2016 there was an [attempt to fix the absolute URL and performance issues](https://github.com/civicrm/civicrm-core/pull/9237) which updated all the `image_URL` fields to relative paths.
- But this would have broken Drupal Views and other tools that rely on the convenience of querying the field from the db and outputting the url directly (in the future, SearchKit would rely on this too).
- A [compromise solution was reached](https://github.com/civicrm/civicrm-core/pull/9241) which rewrites the url at runtime on Civi pages. A `image_URL` like `http://wp.demo/civicrm/contact/imagefile/?photo=abc.jpeg` would get rewritten to `http://wp.demo/civicrm/file?reset=1&filename=abc.jpeg&mime-type=image/jpeg`. For reasons not entirely clear, this goes through a different internal path (`civicrm/file` instead of `civicrm/contact/imagefile`).
- In 2019, thinking it was unused, [Eileen removed support](https://github.com/civicrm/civicrm-core/commit/2762985c11e01ede473d86a33af279bc341f9a46) for passing `filename=` into the `civicrm/file` path, since that endpoint is typically supplied with a file id from the `civicrm_file` table plus a security hash.
- This accidentally broke contact images, leading to [a rushed fix](https://github.com/civicrm/civicrm-core/pull/13663) which added back the ability to get files by name from the `civicrm/file` path (since contact images are not tracked in `civicrm_file` and don't have an `id`). With the benefit of the history laid out above, a better fix might have been to switch to using the `civicrm/contact/imagefile` path and keep the `civicrm/file` path secure.
- In 2021 [I proposed adding](https://lab.civicrm.org/dev/core/-/issues/2755) an `image_file_id` FK field to the `civicrm_contact` table to track uploaded files. This proposal was met with approval, but when I recently tried to implement it I realized that the `civicrm_file` table already has an FK to `civicrm_contact` and circular references are not allowed.
- In 2023 [an option group was added](https://github.com/civicrm/civicrm-core/pull/25904) for the previously unused column `civicrm_file.file_type_id`. One possible use for that field would be to designate a file type of `"contact_image"`.
# Current Situation
The `civicrm_contact.image_URL` field can still store any url string pointing to a file on or off the server. It could point to any image on the internet, and would work fine. But if it's a file uploaded via the Civi UI, it will be an absolute link pointing to the `civicrm/contact/imagefile` path with a `photo=filename` argument. If CiviCRM recognizes this pattern it will rewrite it on core pages to the other path at `civicrm/file`, otherwise it will leave it alone.
For the confused, yes contact images are accessible at two paths, and neither is a direct link to the file on disk:
| Path | `civicrm/contact/imagefile` | `civicrm/file` |
| ------ | ------ | ------ |
| Class | `CRM_Contact_Page_ImageFile` | `CRM_Core_Page_File` |
| Permission | _none_ | "access uploaded files" |
| Args | `photo` | `filename`, `mime-type` |
| Uses | Stored in `image_URL` field as absolute URL. Output by Views & SearchKit | `image_URL` rewritten to this path on Civi pages for logged-in users |
**This situation leads to the following quirks and problems**
1. The absolute url to `civicrm/contact/imagefile` works great in Views and SearchKit... as long as the site name never changes! Otherwise, absolute URLs are a pain.
2. The url is still stored with html-escaped `&` characters that must be unstupified.
3. Anyone can access a contact image via the 1st path if they know the filename, however, the 2nd has a permission check which means logged-in users without "access uploaded files" cannot see contact images even though anonymous users can!
4. The security hash usually required by `civicrm/file` can be circumvented if you know the filename and mime-type. But the risk is mitigated by that path requiring "access uploaded files" permission.
5. There is still no file-management of contact images. Deleting a contact does not delete their image file. Deleting or changing a contact image also doesn't delete the old one.
# Proposal for File Management
1. Stop using `civicrm/file` for all contact images and [restore the patch to remove support for `filename`](https://github.com/civicrm/civicrm-core/commit/2762985c11e01ede473d86a33af279bc341f9a46).
2. Include `cid` as an argument to `civicrm/contact/imagefile` (and update stored paths accordingly) to fix the unindexed query. Also add `is_deleted = 0` to the query.
3. Add an option_value `"contact_image"` to the option group for `civicrm_file.file_type_id`.
4. When uploading a new contact image, create a record in `civicrm_file` table, and designate it `file_type_id` = `"contact_image"`.
5. Also create a record in `civicrm_entity_file` for contact images.
6. Add a virtual APIv4 field for the contact entity `image_file_id` which would allow getting/setting the file id. When setting a new file id, regenerate the `image_URL` with a post hook.
# Thoughts on Absolute URLs
All of these changes would result in better file management, but still doesn't solve the absolute url issue. This is tricky to solve because Views and SearchKit still rely on being able to output the image url directly from a query. Here are a few ideas for that one:
1. Bite the bullet and update all `image_URL` fields pointing to a local file to use a relative URL. SearchKit will still work. Views and other SQL-based tools will still work unless embedded on a remote site. Random offsite images will be unaffected.
2. Keep `image_URL` absolute but add an APIv4 virtual field like `Contact.image` which calculates the url at runtime. This satisfies moree use-cases but at the expense of adding complexity to an already overcomplicated situation.https://lab.civicrm.org/dev/user-interface/-/issues/67Tracker for making CiviCRM's accordions accessible2024-03-06T20:54:20ZnicolTracker for making CiviCRM's accordions accessibleIn #60 at least eight accordion markup patterns were identified, demonstrated in ThemeTest. This issue is to track progress on updating all Civi accordion markup to being accessible.
The table below tracks the progress of all of these p...In #60 at least eight accordion markup patterns were identified, demonstrated in ThemeTest. This issue is to track progress on updating all Civi accordion markup to being accessible.
The table below tracks the progress of all of these patterns: bundling pattern 1 and 8 which use the same JS, then there's just three patterns left to make accessible (four, if another instance of an accordion fieldset can be found).
Statuses are either:
- Recommended - a new/agreed pattern, themes should support
- Supported - old pattern but it's still being used, so themes need to support
- Deprecated - old pattern, not being used, so themes can drop support
| Pattern | Status | Initial PR | Current PR |
|---------|--------|------------|------------|
| 1\. crm-accordion-wrapper & crm-accordion-master-wrapper | Supported | [28415](https://github.com/civicrm/civicrm-core/pull/28415) | 64 instances - [29448](https://github.com/civicrm/civicrm-core/pull/29448) |
| 2\. crm-dashlet | Supported | [29613](https://github.com/civicrm/civicrm-core/pull/29613) | (only instance, so same) |
| 3\. crm-collapsible | Supported | [28430](https://github.com/civicrm/civicrm-core/pull/28430) | 9 instances - 8 fixed in [29533](https://github.com/civicrm/civicrm-core/pull/29533) |
| 4\. fieldset | Deprecated (?) | [28441](https://github.com/civicrm/civicrm-core/pull/28441) | That PR might have been only instance |
| 5\. Extensions table | Deprecated | [28473](https://github.com/civicrm/civicrm-core/pull/28473) | Was only instance |
| 6\. Angular directive | Deprecated | [28467](https://github.com/civicrm/civicrm-core/pull/28467) | Was only instance |
| 7\. FormBuilder generated accordion | Deprecated | [28449](https://github.com/civicrm/civicrm-core/pull/28449) | Was only instance |
| 8\. crm-accordion-master-wrapper | Supported | [28421](https://github.com/civicrm/civicrm-core/pull/28421) | Bundled with pattern 1 |
Testing of new patterns should be on all CMSs with their default admin theme (e.g. Claro on Drupal 9+) and Civi's Greenwich (default) theme.
### Testing [29533](https://github.com/civicrm/civicrm-core/pull/29533)
| File | Testing URL | UI works? | likely related JS? | status | notes |
|------|-------------|-----------|--------------------|--------|-------|
| templates/CRM/Admin/Form/ScheduleReminders.tpl | civicrm/admin/scheduleReminders?reset=1 & click 'add reminder' | yes: d7+d10+sa+wp | none | functional | tested with and without an sms provider enabled |
| templates/CRM/Admin/Page/APIExplorer.tpl | civicrm/api3 & then select an Entity, such as ACLRole | breaks: d7+d10+sa+wp | yes, [APIExplorer.js](https://github.com/civicrm/civicrm-core/blob/735b4e27d76f8cc9f0da3c573217eb35a6250720/templates/CRM/Admin/Page/APIExplorer.js), broken | broken | documentation tab content appears below explorer tab content; entity dropdowns don't have intended behavior |
| templates/CRM/Case/Form/ActivityTab.tpl | civicrm/contact/view/case?reset=1 under Activities/SearchFilters | yes: d7 | none that controls the accordion | functional | some extra borders appear around the details |
### Testing [29448](https://github.com/civicrm/civicrm-core/pull/29448)
Would remove all instances of pattern 1 and pattern 8 (the majority of Civi's accordions).
- [x] CRMAccordionToggle - Contact/Import/Form/Preview.tpl - civicrm/import/contact \> page 3
- [x] CRMAccordionToggle - Financial/Form/BatchTransaction.tpl - civicrm/batchtransaction?reset=1&bid=1 (after creating a batch)
- [x] Contact dashboard issues - Contact/Form/Contact.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/Address.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/CommunicationPreferences.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/CustomData.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/Demographics.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/Notes.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/TagsAndGroups.tpl
- [x] Doesn't open on validation error - Activity/Form/FollowUp.tpl - civicrm/activity?reset=1&action=add&context=standalone
- [x] Doesn't open on validation error - Core/Form/RecurringEntity.tpl - civicrm/activity?reset=1&action=add&context=standalone
- [x] Doesn't open on validation error - Form/attachment.tpl - civicrm/activity?reset=1&action=add&context=standalone, civicrm/activity/email/add
- [x] Other issue - common/fatal.tpl - make an error, ie civicrm/payment
- [x] Other markup issue - Contribute/Form/AdditionalPayment.tpl - civicrm/payment?action=add&reset=1&id=1
- [x] Other markup issue - Custom/Page/CustomDataView.tpl - tested by @shaneonabike and requesting feedback (seems ok)
- [x] Other markup issue - Contribute/Form/Contribution.tpl - civicrm/contribute/add
- [x] Other UX issue - Case/Form/Activity.tpl - civicrm/contact/view/case (add activity modal)
- [x] Other tiny issue - Pledge/Form/Search.tpl - civicrm/pledge/search?reset=1 - tested by @shaneonabike and requesting feedback (seems ok)
- [x] Ajax issue - Contact/Page/View/GroupContact.tpl - civicrm/contact/view -\> Groups
- [x] Ajax issue - Pledge/Form/Pledge.tpl - civicrm/pledge/add?reset=1&action=add&context=standalone
- [x] Remove from PR - Case/Form/ActivityTab.tpl - civicrm/contact/view/case
- [ ] ~~This shouldn't be accordion - Financial/Form/FinancialAccount.tpl - civicrm/admin/financial/financialAccount?reset=1 + add~~ see #68
- [ ] ~~Does this need to be an accordion? - Case/Form/CaseFilter.tpl - civicrm/case~~ see #68
- [ ] ~~Does this need to be an accordion? - Contribute/Form/ContributionPage/Premium.tpl - civicrm/admin/contribute/custom?action=update&reset=1&id=1&selectedChild=premium~~ see #68
- [ ] ~~Does this need to be an accordion? - SMS/Form/Group.tpl - civicrm/sms/send?reset=1 (install & config SMS dummy ext)~~ see #68
- [ ] ~~Does this need to be an accordion? - SMS/Form/Schedule.tpl - civicrm/sms/send?reset=1~~ see #68
- [x] Custom/Form/Search.tpl (e.g. civicrm/activity/search?reset=1)
- [ ] ~~Cannot find to test - Mailing/Form/Approve.tpl~~ (there is a path but class isn't called anywhere, does it do anything? New issue https://lab.civicrm.org/dev/core/-/issues/5055)
- [x] Create membership, and then click Edit/View and see the Related Contributions - Member/Form/Membership.tpl
- [x] Create report, click a report like Constituent Summary, and view Custom fields in Field selection- Report/Form/Tabs/FieldSelection.tpl
- [x] Create report, click a report like Constituent Summary, and view fields in Filter - Report/Form/Tabs/Filters.tpl
Edit: moved review summary to a comment.
#### Related class issues
These files are not affected by [29448](https://github.com/civicrm/civicrm-core/pull/29448) but have references to `.crm-accordion-wrapper`, `.crm-accordion-header` or `.crm-master-accordion-header` and need attention to eliminate those classes.
- Activity/Form/Search.tpl
- Case/Form/CaseView.js
- Campaign/Form/Gotv.tpl
- Contact/Form/Search/AdvancedCriteria.tpl
- Contact/Page/View/CustomDataView.tpl
- Contact/Page/View/Summary.js
- Dashlet/Page/Blog.tpl
- Financial/Form/FinancialAccount.tpl - see above
We will need to merge [29563](https://github.com/civicrm/civicrm-core/pull/29563) as well for theming issue fix.Improve Civi's front-endnicolnicolhttps://lab.civicrm.org/dev/core/-/issues/4618Tracking: Uses of {php} to remove from Smarty in order to allow upgrade to Sm...2023-09-26T03:17:14ZlarsssandergreenTracking: Uses of {php} to remove from Smarty in order to allow upgrade to Smarty 3+This is the complete list remaining (not including those in pending PRs)
- [ ] https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Contact/Form/Task/PDFLetterCommon.hlp#L27 (I think we can get the param directly in Smarty ...This is the complete list remaining (not including those in pending PRs)
- [ ] https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Contact/Form/Task/PDFLetterCommon.hlp#L27 (I think we can get the param directly in Smarty 3 or maybe it would be OK to hardcode docx and odt in here)
- [x] https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Admin/Page/APIExplorer.js#L752 (APIv3 Explorer ouputs {php} when we have an array, but in Smarty 3 we can pass in the array, so this can be removed)
- [ ] https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Campaign/Page/Petition/SocialNetwork.drupal#L28
- [ ] https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/common/accesskeys.hlp#L11 (Could maybe redo this in JS)
- [ ] https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/ACL/Header.tpl#L17
- [ ] https://github.com/civicrm/civicrm-core/blob/master/xml/templates/civicrm_msg_template.tplhttps://lab.civicrm.org/dev/financial/-/issues/60Transaction IDs for a contribution that are initially null are always null2021-08-06T13:19:57ZfrancescbassasTransaction IDs for a contribution that are initially null are always nullThis ticket is the result of the inquiry in this other https://lab.civicrm.org/dev/core/issues/468
**"Normal behaviour"**
1. Create a contribution with transaction ID
![normal-1](/uploads/4208ac1852698fdf61e003d500174d31/normal-1.png...This ticket is the result of the inquiry in this other https://lab.civicrm.org/dev/core/issues/468
**"Normal behaviour"**
1. Create a contribution with transaction ID
![normal-1](/uploads/4208ac1852698fdf61e003d500174d31/normal-1.png)
2. Visualize contribution, transaction ID is present
![normal-2](/uploads/37bab7a87afad68b094dfa5eba16ee9b/normal-2.png)
3. Edit payment details and set a different transaction ID
![normal-3](/uploads/e04d3ed2b91215f593e403310c48b9ad/normal-3.png)
4. Visualize contribution, new transaction ID is appended to the old transaction ID
![normal-4](/uploads/19308ed662e8920da29e234c49c69608/normal-4.png)
**Buggy behaviour**
1. Create a contribution with transaction ID null
![null-1](/uploads/38cd6b38e9ccd16e852c5c7e0c51c3d6/null-1.png)
2. Edit payment details and set a transaction ID value
![null-2](/uploads/25f183f29ced11ae4398cfa8611ec31b/null-2.png)
3. Visualize contribution, transaction ID isn't present
![null-3](/uploads/de18a6e9656acbd6d29029b3c84023db/null-3.png)https://lab.civicrm.org/dev/core/-/issues/4462Transactional Authentication (Page-level auth tokens)2024-03-01T19:59:17Zaydunsaidan.saunders@squiffle.ukTransactional Authentication (Page-level auth tokens)Overview
----------------------------------------
Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transacti...Overview
----------------------------------------
Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transactional one.
See [this snippet](https://lab.civicrm.org/-/snippets/92 ) for the background describing how to use authenticated links with forms. This documents the resulting conversation with @totten [here](https://chat.civicrm.org/civicrm/pl/trubx7xwui878nsz3w6ujmf6oc):
(@totten says:) I'd like some language to describe two ways of approaching customized UX for constituents.
- Hypothetical scenario
- You send an email 12 months after a prior donation. You thank the donor for the previous contribution. The message includes some links to update communication preferences, browse past donations, or make a new donation.
- UX Approaches
1. **Transactional Approach / One form at a time / Strict Pageflow / Page-Level Auth**: The email has 3x hyperlinks. Each goes to different form/page. Each link has diff auth code (which confers access to exactly one form).
2. **Portal Approach / Multiple forms at discretion / Open Pageflow / Session-Level Auth**: The email has 3x hyperlinks. All go to pages within the same portal. The user opens the first page which takes their interest. On that page, there are more links (eg via prose or navbar) to go checkout the others.
I don't know a good/simple way to say that one is better than the other. but they are different. I suspect there's some Venn diagram of organizational-scenarios (some better suited to 1; some to 2; some to either 1 or 2)
The current auth-code mechanism is better for "Portal Approach/Open Pageflow" -- and it's worse for Transactional Approach/Strict Pageflow"
(that's not b/c "Open Pageflow" is better -- but at the time of its writing, it was the easier one to support)
From a low-level POV, the auth-codes for them would differ like this:
- For portal/open pageflow, it generates this token -- which is basically a login-token
- -The custom forms use "Role-based" security-(Maybe either security model is ok in this context...)
- For transactional/strict pageflow, you might expect...
- It needs a fine-grained token like this (pseudocode)
```
$bearerToken = "Bearer " . $jwt->encode([
'exp' => $expires,
'sub' => "cid:" . $contactId,
'scope' => 'api4',
'api4.whitelist' => [
['Afform', 'prefill', ['name' =>'xyz']],
['Afform', 'submit', ['name' =>'xyz']],
]);
```
- In PHP, need a mechanism to accept those tokens
- In JS/HTML, need a mechanism to relay that token
- The custom forms use "Form-based" security
See also
--------
- #4463: Authentication tokens: session already active - same user
- #4464: Authentication tokens: session already active - different userhttps://lab.civicrm.org/dev/core/-/issues/4167Transferred to Link in View Event Registration for {participant} Goes to a Pr...2023-03-09T09:20:26ZLKuttnerTransferred to Link in View Event Registration for {participant} Goes to a Previous EventSteps to Reproduce:
- View an event registration that has been transferred to another participant.
- In the Status line, Click the name of the participant that the registration has been transferred to.
- Example: _Status | Transferred (...Steps to Reproduce:
- View an event registration that has been transferred to another participant.
- In the Status line, Click the name of the participant that the registration has been transferred to.
- Example: _Status | Transferred (Transferred to Megan Nedzinski)_
- The link takes you to the registration for the first event that the person was ever registered for.
- The link does not take you to the latest registration that was just transferred to that contact.
- This only happens in the View Event Registration for {participant} page.
- In the Edit Event Registration for {participant} page, clicking the equivalent link does take you to the correct event.
This is using CiviCRM 5.55.1 on Drupal 7. I just noticed this and don't know how long this behavior has been in effect.https://lab.civicrm.org/dev/translation/-/issues/75Translatable fields within Extension table2022-04-21T20:39:46ZseamusleeTranslatable fields within Extension tableAt present the CiviCRM i18n widget code and also the i10n schema code depend on the functions in the schema structure file returning an array of fields or html widgets. The Schema Structure file does not contain any information about tab...At present the CiviCRM i18n widget code and also the i10n schema code depend on the functions in the schema structure file returning an array of fields or html widgets. The Schema Structure file does not contain any information about tables other than core tables so for example in the JMA Grant Applications extension if we wanted to make the title or the introductory text field translatable we would have to hack the schema structure file.
I would like to propose that we create 3 new Events or similar to handle altering the fields, indices and widgets functions in the schema structure file.https://lab.civicrm.org/dev/translation/-/issues/27Translation option missing for "on behalf of label"2021-06-02T18:01:34ZMartinTranslation option missing for "on behalf of label"I might be misunderstanding how this is supposed to work, but here's the situation that I'm seeing. I have multilingual for civi turned on, and have a contribution page. For the text/longtext fields there is a translation icon next to th...I might be misunderstanding how this is supposed to work, but here's the situation that I'm seeing. I have multilingual for civi turned on, and have a contribution page. For the text/longtext fields there is a translation icon next to the field label in the admin when configuring the page. But when I enable the "allow on behalf of" option, the "on behalf of label" does not have this translation option showing (see screenshot). So it seems that we're not able to provide the right text to the end user in this case.
In addition, when displaying the translated page the following Drupal error shows:
> Notice: Undefined index: for_organization in CRM_Contribute_Form_ContributionBase->buildComponentForm() (line 976 of /home/mysite/public_html/sites/all/modules/civicrm/CRM/Contribute/Form/ContributionBase.php).
Running civicrm 5.12.4 on drupal 7.66 with php 5.6 (I know, I know). Issue was also seen previously on civi 4.7.31.
[civi_trans_issue_1](/uploads/a300619c6ab7cbcabb43e521f7bd46ed/civi_trans_issue_1.jpg)https://lab.civicrm.org/dev/core/-/issues/2396Translation support for Afforms & Managed Search Displays2024-02-07T17:45:35ZseamusleeTranslation support for Afforms & Managed Search DisplaysAs per https://lab.civicrm.org/extensions/afform/-/issues/22 and https://lab.civicrm.org/extensions/afform/-/issues/8 looks like there needs to be some improvements to support multilingual sites in AfformAs per https://lab.civicrm.org/extensions/afform/-/issues/22 and https://lab.civicrm.org/extensions/afform/-/issues/8 looks like there needs to be some improvements to support multilingual sites in Afformhttps://lab.civicrm.org/dev/core/-/issues/3818Trigger based logging - improve archivability2022-08-30T10:59:52ZeileenTrigger based logging - improve archivabilityWe would like to time-limit our database logging but there is a challenge when deleting old rows from the `log_` tables.
Example rows from `log_civicrm_contact`
| log_date| log_action |id|first_name|
| ------ | ------ |------ |------ ...We would like to time-limit our database logging but there is a challenge when deleting old rows from the `log_` tables.
Example rows from `log_civicrm_contact`
| log_date| log_action |id|first_name|
| ------ | ------ |------ |------ |
| 2015-11-09 | Initialize |8|Bob|
| 2018-09-09 | Update |8|Robert|
| 2022-10-09 | Update |8|John|
In each case the rows are logged to have the status of the updated value. So on 2022-10-09 the value in `civicrm_contact` is "John"
If the change was made in error the change can be rolled back to the last change - ie 'Robert'
However, if we say that we don't want to retain logging data older than 4 years and we have just deleted all rows older than than the after the change the table looks like this
| log_date| log_action |id|first_name|
| ------ | ------ |------ |------ |
| 2022-10-09 | Update |8|John|
And we can no longer roll back the change
The options seem to be
- Have an archive routine that adds an `initialization ` of current value when we truncate
- Switch the mechanism to log the PREVIOUS value not the current value on each update (this means the live table would need to be considered when calculating any diffs)https://lab.civicrm.org/dev/core/-/issues/2114Trigger-based logging doesn't log if just changing a letter to upper/lower case2023-06-29T12:55:38ZDaveDTrigger-based logging doesn't log if just changing a letter to upper/lower case1. Turn on logging. (Admin - System Settings - Misc - Logging).
1. Change the first name of a contact just changing e.g. the first letter from upper to lower case.
1. Either look in the database in log_civicrm_contact or go to CiviReport...1. Turn on logging. (Admin - System Settings - Misc - Logging).
1. Change the first name of a contact just changing e.g. the first letter from upper to lower case.
1. Either look in the database in log_civicrm_contact or go to CiviReports - Contact Reports - Contact Logging.
1. Change has not been logged.
It's because the standard collation for civi is the case-insensitive xxx_unicode_ci or possibly xxx_general_ci. You might have also changed it manually to use the same as your CMS but is likely still case-insensitive. And in mysql 8 the default utf8mb4_0900_ai_ci is also accent-insensitive (i.e. `é` is treated the same as `e`), if you manually changed your civi tables to use that.
The logging triggers should probably use `xxx_bin`. Related but separate: https://github.com/civicrm/civicrm-core/pull/18721https://lab.civicrm.org/dev/translation/-/issues/74ts() - Allow symbolic placeholders2022-01-27T13:24:34Ztottents() - Allow symbolic placeholdersOverview
---------
When writing translatable strings, placeholders must be numeric.
This leads to some quirky strings - eg if you're outputting a title and subtitle ("Some Chapter: Some Section"), the only way to encode that is `ts('%1...Overview
---------
When writing translatable strings, placeholders must be numeric.
This leads to some quirky strings - eg if you're outputting a title and subtitle ("Some Chapter: Some Section"), the only way to encode that is `ts('%1: %2')`. This string should be translatable because the layout is language dependent (eg LTR/RTL; eg punctuation-preferences), but the exported string will become meaningless when presented in Transifex (or similar). And it may be confused with other/similar strings.
Current behavior
-----------------
The function `ts(string $str, array $params)` accepts the following `$params`:
* Functional params (`count`, `plural`, `context`, `domain`, `escape`, `skip_translation`)
* Substitution params (numeric keys; `0`, `1`, `2`, ...)
As in:
```php
echo ts('Hello, %1!', [
1 => $name,
]);
echo '<li>' . ts('%1: %2', [
1 => $title,
2 => $subtitle,
]) . '</li>';
echo ts('The directory %1 is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %1. Please check your file permissions.',
'count' => count($notWritableDirs),
1 => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts 1=Bob}Hello %1!{/ts}
<li>{ts 1="Title" 2="Subtitle"}%1: %2{/ts}</li>
```
~~Proposed behavior (draft 1; symbol-prefix)~~
-----------------
Any `$params` which begin with a symbol (`%`, `_`, `{`, `@`, etc) will be used for variable substitution.
The earlier examples remain valid. Additionally, these examples are also valid:
```php
echo ts('Hello, %name!', [
'%name' => $name,
]);
echo '<li>' . ts('%title: %subtitle', [
'%title' => $title,
'%subtitle' => $subtitle],
) . '</li>';
echo ts('The directory %dir is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %dir. Please check your file permissions.',
'count' => count($notWritableDirs),
'%dir' => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts _NAME_=Bob}Hello _NAME_!{/ts}
<li>{ts _title_="Foo" _subtitle_="Bar"}_title_: _subtitle_{/ts}</li>
```
Proposed behavior (draft 2; capitalization-based)
-----------------
Any `$params` which begin with a capital letter (`[A-Z]`) will be used for variable substitution.
```php
echo ts('Hello, %NAME!', [
'NAME' => $name,
]);
echo '<li>' . ts('%TITLE: %SUBTITLE', [
'TITLE' => $title,
'SUBTITLE' => $subtitle],
) . '</li>';
echo ts('The directory %DIR is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %DIR. Please check your file permissions.',
'count' => count($notWritableDirs),
'DIR' => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts NAME=Bob}Hello %NAME!{/ts}
<li>{ts TITLE="Foo" SUBTITLE="Bar"}%TITLE: %SUBTITLE{/ts}</li>
```
Comments
---------
Either draft (using symbol-prefix or using uppercase) should avoid conflicts with existing strings+params. (Existing params do not begin with symbols and they are not uppercase.)
A couple factors in choosing a symbol:
* Using `%` is most consistent with current `ts()` style.
* `ts()` is used in multiple programming languages. Each has different compatibility/constraints.
* Pure PHP and pure JS are fairly flexible (`%FOO`, `{{FOO}}`, `_FOO_`, etc)
* Smarty-HTML (`{ts KEY=VALUE}...{/ts}`) is pretty limited. The bottleneck is how it parses the `KEY`.
* Angular-HTML (`{{ts('...')}}`) is in the middle. It's OK for `{{ts('%FOO')}}`, `{{ts('_FOO_')}}`, but I wouldn't count on `{{ts('{{FOO}}')}}`.
* If you want one symbol that works everywhere, `_` is probably it.
* Being flexible about symbol may be good for compatibility in the most contexts.
I suppose that the uppercase approach constrains style a bit, but maybe that's a good thing - ie you get more consistency in how `ts()` looks across environments.
Questions
---------
Are there any constraints in other layers -- eg Transifex, civistrings -- which would prevent this?
As far as I know, the only constraints which require using numeric-keys are baked into `ts()` itself.