CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-02-04T05:03:25Zhttps://lab.civicrm.org/dev/core/-/issues/3479make the hook usable by passing the sql2024-02-04T05:03:25Zyashodhamake the hook usable by passing the sqlCurrently, we are not passing the sql in the _alterReportVar_ hook.
`CRM_Utils_Hook::alterReportVar('sql', $this, $this);`
Objective is to make the hook usable by passing the sql instead of redundant params.Currently, we are not passing the sql in the _alterReportVar_ hook.
`CRM_Utils_Hook::alterReportVar('sql', $this, $this);`
Objective is to make the hook usable by passing the sql instead of redundant params.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2873Exporting related contact's information on a contact that is a subtype fails2024-02-02T05:03:23Zfabian_SYSTOPIAExporting related contact's information on a contact that is a subtype failsOverview
----------------------------------------
There is an old bug described on the old issue tracker that prevents related contact information to be exported via the UI if one of the contacts is a subtype.
https://issues.civicrm.org/...Overview
----------------------------------------
There is an old bug described on the old issue tracker that prevents related contact information to be exported via the UI if one of the contacts is a subtype.
https://issues.civicrm.org/jira/browse/CRM-16693
Reproduction steps
----------------------------------------
1. Search for any contacts, e.g. a subtype
1. Select at least one contact and choose "export contacts"
1. choose select fields for export
1. select display name or anything else of the contact (will be exported correctly)
1. select a field of a related contact (relationship) e.g. display name
Current behaviour
----------------------------------------
If one of the contacts is a contact subtype or the relationship is defined to be only allowed among subtypes the exported columns won't contain any data (data of the "main contact" will be exported correctly).
Expected behaviour
----------------------------------------
Data of related contact should be exported as well.
Environment information
----------------------------------------
* Browser: all
* CiviCRM: Since 4.6.x still occuring in 5.35.x
Comments
----------------------------------------
We may have funding to fix this bug and would appreciate an estimate from the core team.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3489Increase field size for mailing bounce type2024-01-29T10:07:13ZKurund JalmiIncrease field size for mailing bounce typeThe database fields in civicrm_mailing_bounce_type are too restrictive. The name field is limited to 24 characters and the description is limited to 255 characters. This isn’t long enough for the name and description provided by some ema...The database fields in civicrm_mailing_bounce_type are too restrictive. The name field is limited to 24 characters and the description is limited to 255 characters. This isn’t long enough for the name and description provided by some email service providers - e.g. AWS SES.
I propose that the name field should be increased to 256 characters (`VARCHAR(256)`) and the description field should be increased to 2048 characters (`VARCHAR(2048)`).https://lab.civicrm.org/dev/core/-/issues/1256Improve error handling to always throw exceptions and never abend2024-01-27T05:03:27ZAndrew WestImprove error handling to always throw exceptions and never abendWe're interested in funding a fix to ensure errors are always thrown as exceptions, as mentioned here: https://issues.civicrm.org/jira/browse/CRM-11193 and here: https://lab.civicrm.org/dev/core/issues/395 and here: https://lab.civicrm.o...We're interested in funding a fix to ensure errors are always thrown as exceptions, as mentioned here: https://issues.civicrm.org/jira/browse/CRM-11193 and here: https://lab.civicrm.org/dev/core/issues/395 and here: https://lab.civicrm.org/dev/core/issues/749
If someone could tag this with 'paid-issue-queue' I'd appreciate it.
Our particular interests are:
* catching errors when generating groups for mailings. Currently if these fail a mailing can cheerily sail on without the correct exclusion group
* catching smarty errors in mailings. These currently fail silently and can kill the scheduled jobs list
It seems like both of these are covered by CRM-11193.
I'm not promising we can fund the whole thing, but we can at least pay for time spent investigating what needs to be done.https://lab.civicrm.org/dev/core/-/issues/3454Migrate hook_civicrm_caseTypes to hook_civicrm_managed2024-01-26T05:03:29ZtottenMigrate hook_civicrm_caseTypes to hook_civicrm_managedOverview
---------
Since v4.x, `hook_civicrm_caseTypes` has provided a way to register a case-type using a stored file from an extension. `hook_civicrm_managed` was recently expanded (#3429 for 5.50) in a way that appears to provide a s...Overview
---------
Since v4.x, `hook_civicrm_caseTypes` has provided a way to register a case-type using a stored file from an extension. `hook_civicrm_managed` was recently expanded (#3429 for 5.50) in a way that appears to provide a superset of the functionality. During review of @herbdool's https://github.com/civicrm/civicrm-core/pull/23313, @colemanw suggested deprecating `hook_caseTypes` in favor of `hook_managed`.
This issue is to identify the steps/phases of a migration.
Pro/Con
---------
* Reasons to transition `hook_civicrm_caseTypes` => `hook_civicrm_managed`
* They support the same use-case. Having more than one way to do the same thing can be confusing.
* `hook_managed` is more generic. You get more utility/leverage from understanding it.
* `hook_managed` has more options vis-a-vis lifecycle, cleanup, etc.
* Reasons not to transition `hook_civicrm_caseTypes` => `hook_civicrm_managed`
* If it ain't broke, don't fix it.
* `hook_caseTypes` has multiple mappings which appear to work together (ie `CRM_Case_ManagedEntities`: `CaseTypes`,`ActivityTypes`,`RelationshipTypes`).
* This specific application of `hook_managed` is new. Needs more usage to see if it's fit-to-purpose.
Transition Path
---------------
IMHO, the transition would look something like this:
* Near term / Phase 1
* Do some testing around extension lifecycle/upgrades - eg if you upgrade an extension (*getting a new CaseType `definition` that adds, edits, removes some ActivityType*), then... do the interdependent things update properly? What happens if you've edited the `ActivityType` locally or added another `ActivityType`? Do policies like `cleanup=>unmodified` or `cleanup=>unused` actually work? (*I expect these to be somewhat sensible, since each part seems to have satisfactory precedent; but I encourage playing with it during QA, since this is a bit unusual and it's important to the story of "managed CaseType".*) Perhaps publish an example extension that shows that the technique is fit-for-purpose.
* Mid-term / Phase 2
* Add some docs which tell the story of exporting via `civicrm/api4` -- eg an alternative to https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type
* Try doing a conversion from `xml/case/*.xml` to `*.mgd.php`. Make sure that IDs/FKs (`case_type_id`, `activity_type_id`, etc) are stable.
* Remove https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type and maybe `civix generate:case-type` (Leave a pointer to the new docs.)
* Update `CRM_Case_ManagedEntities` and/or `mixins/case-xml` to emit a warning. Encourage folks to convert to `mgd`.
* (*Stretch goal*) Add a step to `civix upgrade` to auto-convert `*.xml` to `*.mgd.php` (or at least show a warning about the XML files). (See also: https://github.com/totten/civix/tree/master/upgrades)
* Long-term / Phase 3
* Remove `hook_caseTypes` aka `mixins/case-xml` from core
* Remove `hook_caseTypes` aka `mixins/case-xml` from civixhttps://lab.civicrm.org/dev/core/-/issues/3429API4: Make CaseType a managed entity2024-01-24T14:08:18ZherbdoolAPI4: Make CaseType a managed entityOverview
----------------------------------------
Allow CaseType to be a managed entity so it can be exported via api4.
Example use-case
----------------------------------------
1. Go to `/civicrm/api4`
1. Select CaseType and Export
C...Overview
----------------------------------------
Allow CaseType to be a managed entity so it can be exported via api4.
Example use-case
----------------------------------------
1. Go to `/civicrm/api4`
1. Select CaseType and Export
Current behaviour
----------------------------------------
Cannot export and use as a managed entity.https://lab.civicrm.org/dev/core/-/issues/3442Allow other services to standardize addresses and spin off CRM_Utils_Address_...2024-01-21T05:03:28ZherbdoolAllow other services to standardize addresses and spin off CRM_Utils_Address_USPS into an extensionOverview
----------------------------------------
Currently `CRM_Core_BAO_Address::fixAddress` is hardcoded to use `CRM_Utils_Address_USPS` alone. It allows an "address_standardization_provider" to be set but it will only recognize USPS...Overview
----------------------------------------
Currently `CRM_Core_BAO_Address::fixAddress` is hardcoded to use `CRM_Utils_Address_USPS` alone. It allows an "address_standardization_provider" to be set but it will only recognize USPS.
Proposed behaviour
----------------------------------------
Allow for other providers and restructure so that USPS is not hardcoded here. USPS could extend an `AddressStandardization` class or something like that. Could use `CRM_Utils_GeocodeProvider` for inspiration.https://lab.civicrm.org/dev/core/-/issues/4860VTIMEZONE block in ICS file publishes DSTART in wrong timezone2024-01-17T23:01:42ZjamieVTIMEZONE block in ICS file publishes DSTART in wrong timezoneA lot of great work went into fixing our ICS timezone support in #2887!
But, I _think_ there is still one small problem with timezone support.
I'm testing with the ICS file generated by the Montreal Developer Training on February 26th ...A lot of great work went into fixing our ICS timezone support in #2887!
But, I _think_ there is still one small problem with timezone support.
I'm testing with the ICS file generated by the Montreal Developer Training on February 26th (https://civicrm.org/civicrm/event/ical?reset=1&id=1745). The event is supposed to start at 9:00 AM America/New_York time.
I'm using Thunderbird. I have my Thunderbird timezone set to America/Los_Angeles. It's important to set your calendar timezone to a timezone that does not match the event time zone to replicate the problem.
When I import the ICS file, my calendar shows it as starting at 1:00 am America/Los_Angeles time, which would be 4:00 am America/New_York time. The reason it's off is because Thunderbird percieves the correct time to be 9:00 am UTC rather than 9:00 am America/New_York.
Here are the relevant parts of the ICS file.
First, the timezone is defined:
```
BEGIN:VTIMEZONE
TZID:America/New_York
BEGIN:STANDARD
TZOFFSETFROM:-0500
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20240226T140000
END:STANDARD
END:VTIMEZONE
```
Then, the event date start is defined:
```
TSTAMP;TZID=America/New_York:20240226T090000
DTSTART;TZID=America/New_York:20240226T090000
DTEND;TZID=America/New_York:20240227T170000
```
The problem is with the timezone definition, specifically:
`DTSTART:20240226T140000`
This represents the start time in UTC. But, the [standards](https://www.rfc-editor.org/rfc/rfc5545#section-3.6.5) says:
> The mandatory "DTSTART" property gives the effective onset date
and local time for the time zone sub-component definition.
"DTSTART" in this usage MUST be specified as a date with a local
time value.
In other words, it should be the local time, not UTC. In this case: `DTSTART:20240226T090000`.
Making that adjustment causes it to import properly in Thunderbird.
I'm happy to work on this, but would love some feedback to make sure I'm not offbase on anything. I know @justinfreeman did a lot of work on this in #2887 so maybe has some thoughts.5.71.0https://lab.civicrm.org/dev/core/-/issues/1107create the ability to programaticially create a smart group based on an apiv4...2024-01-16T05:03:24Zeileencreate the ability to programaticially create a smart group based on an apiv4 explorer 'get' actionSub issue of https://lab.civicrm.org/dev/core/issues/1106Sub issue of https://lab.civicrm.org/dev/core/issues/1106https://lab.civicrm.org/dev/core/-/issues/4826Add is_new as a field on membership api or possibly via membership_status2024-01-05T03:42:40ZeileenAdd is_new as a field on membership api or possibly via membership_statusI've been thinking about https://github.com/civicrm/civicrm-core/pull/28185 & have concluded that the way to determine if it is a new membership or renewal is to check for the new membership status.
However, that is not actually straig...I've been thinking about https://github.com/civicrm/civicrm-core/pull/28185 & have concluded that the way to determine if it is a new membership or renewal is to check for the new membership status.
However, that is not actually straight forward since we can't use {membership.membership_status_id.name} in case they have modified the statuses.
I'm thinking maybe an api calculated field (exposed as a token)
Then in the template it would be something like
```
{if {membership.membership_status_id.is_new|boolean}}
Signup
{else}
Renewal
{/if}
```
One concern with the above is that if you re-sent it after the status had changed from new (3 months by default) if would show 'renewal'. Obviously people can customise the templates, as they do the membership types, so we don't have to catch every possibility. We might consider doing instead
```
{if {membership.membership_status_id.is_new|boolean}}
Signup
{elseif !{contribution.receive_date|boolean}}
-- hasn't been sent already so we can be somewhat confident
Renewal
{else}
-- some mealy mouthed generic alternative
{/if}
```5.69.0https://lab.civicrm.org/dev/core/-/issues/3041SearchKit - Ability to COUNT() without any grouping2023-12-29T03:21:15ZeileenSearchKit - Ability to COUNT() without any groupingWhen using aggregates in search kit the assumptions about when it is good to offer aggregates is a bit off.
Scenario - contact has a custom field of type money & search has 2 tables - contribution and contact
Here are some things I can...When using aggregates in search kit the assumptions about when it is good to offer aggregates is a bit off.
Scenario - contact has a custom field of type money & search has 2 tables - contribution and contact
Here are some things I can't do:
- group by contact ID and then get a SUM of total_amount
- group by contact ID or contribution ID and get a sum of my custom money field
- group by contact ID and also display COUNT for contact id - or display name - this is useful to create a micro widget that gives a count of contacts that meet a criteria & which links to somewhere else.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3131Enable selective visibility of contacts in search using a profile2023-12-07T05:03:22ZspalmstromEnable selective visibility of contacts in search using a profileOverview
----------------------------------------
In some environments it may be desirable to limit what most users can see when searching for contacts using a profile, for example restricting visibility to first name and city unless th...Overview
----------------------------------------
In some environments it may be desirable to limit what most users can see when searching for contacts using a profile, for example restricting visibility to first name and city unless the user has the right to view the contact. Currently, whilst you can restrict what the user sees using the profile, mapping for example, reveals the address and clicking on the icon on the map reveals the contact details. An improvement would be to disable mapping and the ability to view contact details unless the user has the rights to view the contact in question.
Example use-case
----------------------------------------
1. Create a suitable profile.
1. Enter a search term that will return contacts to which the user has view rights and some to which they have not.
Current behaviour
----------------------------------------
![image](/uploads/ddd0f64ae64632f662e430d2453002a7/image.png)
Proposed behaviour
----------------------------------------
![image](/uploads/c1fdaeafe57911839966ff83a460ee78/image.png)
Note that the user has view rights on 851 but not on 853. Notice that the first and last name is blanked out. If they had no view rights on any contact, the _Map these contacts_ would not appear. The little person icon does not appear if the user cannot view all contacts (as clicking on it doesn't do much). If the user has no rights to view any of the contacts, the _Last and First Name_ column does not appear either.
![image](/uploads/82d2fd5cfdad41d8f55eabd49885431c/image.png)https://lab.civicrm.org/dev/core/-/issues/3133Extend Authx functionality to support validation of externally generated JWTs2023-12-07T00:42:41ZJohn TwymanExtend Authx functionality to support validation of externally generated JWTsOverview
----------------------------------------
We would like to extend AuthX's functionality so that it can validate JWTs generated/signed by third party systems. The motivation for this is that we use auth0 for authZ/authN with CiviC...Overview
----------------------------------------
We would like to extend AuthX's functionality so that it can validate JWTs generated/signed by third party systems. The motivation for this is that we use auth0 for authZ/authN with CiviCRM. We're building new applications that need to query Civi via its API _as the user rather than as the client apps themselves_.
Creating API keys for every user is not feasible. Accessing the AuthX-supported API endpoint and supplying a valid JWT for the user is what we're keen to implement.
Current behaviour
----------------------------------------
AuthX can validate JWTs that have been generated by the same CiviCRM installation.
Proposed behaviour
----------------------------------------
Implement code that dispatches a new Symfony event which would allow an extension to override how the scope and sub claims are validated by the AuthX framework (for example currently, if it doesn't start with `cid` no claim can be validated).
This would make it possible to validate externally generated/signed JWTs.
Comments
----------------------------------------
Tim and I had a chat about this [a while ago](https://chat.civicrm.org/civicrm/pl/acbnapozsbgimrsmh4bqdrtbwh). That conversation proved the basis for writing up an implementation for this improvement. We'd love to see it reviewed, merged, etc. We'll raise a Pull Request accordingly and I'll update this Issue here with the link.
We've also written [a CiviCRM extension that leverages this new functionality](https://github.com/australiangreens/civiauth0jwt), to make it possible for people using auth0 as their IdP to use CiviCRM's API with user permissions.https://lab.civicrm.org/dev/core/-/issues/3129The way the Most Recent Activity column on Find Cases is calculated makes no ...2023-12-04T05:03:27ZDaveDThe way the Most Recent Activity column on Find Cases is calculated makes no senseIt shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do no...It shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do not have recent activity. For those cases, the column displays blank, when it really should simply display the most recent activity, whenever it was.
To reproduce, create a case and complete an activity. Wait 2 weeks. Then do a find cases and look at the Most Recent Activity column for that case.
Does Find Cases even need this column?https://lab.civicrm.org/dev/core/-/issues/3477SearchKit - dashboard tables2023-12-03T16:32:00Zaydunsaidan.saunders@squiffle.ukSearchKit - dashboard tablesOverview
----------------------------------------
This is about how we can produce dashboard-like summary data with SearchKit to replace existing dashboards and make them more customisable.
For example, consider the Cases dashboard:
...Overview
----------------------------------------
This is about how we can produce dashboard-like summary data with SearchKit to replace existing dashboards and make them more customisable.
For example, consider the Cases dashboard:
- the rows are Case Types
- the columns are the values of Case Status
- the table cells are counts of matching cases, linked to another search
Option 1
--------
SearchKit can produce the counts with eg:
![image](/uploads/16d551f0332f28f4f2a5ef8a6e4a1ff4/image.png)
Maybe a new Display type could restructure the data to produce the desired format.
(Note that is should be based off of CaseType rather than Cases so that types with no cases are shown. But CaseType is not currently available.)
Option 2
--------
See https://gist.github.com/aydun/d49197c81205b463ef5cdef38c97b317
The recently added data segmentation functionality adds 'virtual fields' for group-by purposes. Maybe we could add virtual fields based around the idea of the gist to create virtual fields from an option group so an option group of case_status becomes a set of fields `sum(status_id=1), sum(status_id=2)` etc.
However, I don't think SearchKit/Api4 can produce sql like that - but maybe it can!
Both of these would need to accommodate linking the cells to another parameterized search.
Option 3
----------------------------------------
Something else ...https://lab.civicrm.org/dev/core/-/issues/3078Support for HEIC/HEIF Images2023-11-26T05:03:23ZpbarmakSupport for HEIC/HEIF ImagesPer a stackexchange question I posed here (https://civicrm.stackexchange.com/questions/41314/handling-heic-heif-photos), it would be beneficial to add support for heic/heif images, both when adding a photo for a contact and displaying th...Per a stackexchange question I posed here (https://civicrm.stackexchange.com/questions/41314/handling-heic-heif-photos), it would be beneficial to add support for heic/heif images, both when adding a photo for a contact and displaying that same photo.https://lab.civicrm.org/dev/core/-/issues/1416Export to PDF with useful filename2023-11-22T05:03:22ZCoreyBurgerExport to PDF with useful filenameIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titleIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titlehttps://lab.civicrm.org/dev/core/-/issues/3053Usability issue reported by user: All Reports page overrides report results s...2023-11-20T05:03:18ZDevAppUsability issue reported by user: All Reports page overrides report results settingWhen clicking on a report name on the All Reports page located at /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Freport%2Flist&reset=1
The resulting link loads the report with output=criteria on the end. This stops the default parameters ...When clicking on a report name on the All Reports page located at /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Freport%2Flist&reset=1
The resulting link loads the report with output=criteria on the end. This stops the default parameters of the results from loading, which was set to view results. The user expected results to appear when loading the report per the saved report setting. The result to the user is the report is broken.
The output=criteria is overriding the saved report behaviour. Whilst there is a view results button the right hand side of the All Reports page, it does create some confusion to the user with consistency. Perhaps if the setting is already set on the report to view results, the output=criteria could be removed from that link to create consistency... Or the GUI clearer about why the report wasn't run.
This isn't a bug, but more a usability issue.https://lab.civicrm.org/dev/core/-/issues/724For many countries other than USA, state is displayed as a number instead of ...2023-11-17T05:03:23ZIan KellingFor many countries other than USA, state is displayed as a number instead of a stringRepro:
Go to https://civicrm.demo.civihosting.com which is running 5.10.0 when
I tested this. Create a new contact, add an address in japan, choose a
state from the drop down box and click save. Then view the contact. In the state field,...Repro:
Go to https://civicrm.demo.civihosting.com which is running 5.10.0 when
I tested this. Create a new contact, add an address in japan, choose a
state from the drop down box and click save. Then view the contact. In the state field,
you will see a number instead of a state name. This seems to happen with
many countries.
We printed mailing labels that had numbers instead of the state names
and we don't know how many were or were not delivered. Please consider
this a high priority bug.https://lab.civicrm.org/dev/core/-/issues/2981Pledge improvements2023-11-15T05:03:18ZyashodhaPledge improvementsCiviPledge improvements
-------------------------
There are frequent discrepancies between received and pledged payments, the following specifications detail each of the suggested improvements.
Technical Specifications
-----------------...CiviPledge improvements
-------------------------
There are frequent discrepancies between received and pledged payments, the following specifications detail each of the suggested improvements.
Technical Specifications
-------------------------
- Delete pledge behavior
When a pledge is deleted, currently all associated payments are also deleted. Instead, only delete the records in the civicrm_pledge and civicrm_pledge_payment tables.
- Unlink pledge payment
In the View Payment pop-up window associated with a pledge payment, add a button ‘Unlink’ next to the ‘Delete’ button.
![unlink](/uploads/9844b5fdddc9456508af0560266d5f12/unlink.png)
Pressing this button will reset the pledge_payment record (ie. reset contribution_id, actual_amount, and status_id fields to blank/null), but not delete the contribution itself.
- Delete scheduled payment
In the Edit Scheduled Payment pop-up window associated with scheduled pledge payments, add a button ‘Delete’ next to the ‘Save’ button.
![del](/uploads/4c5aa52d6d471d8ebfd583720b1bb969/del.png)
Pressing this button will delete the scheduled pledge payment and reduce the pledge amount (ie. civicrm_pledge.amount) by the corresponding amount.
- Add scheduled payment
In the Edit Scheduled Payment pop-up window associated with scheduled pledge payments, add a button ‘Save and New’ next to the ‘Save’ button.
![add](/uploads/1fcb8f2ee9bb03e91745bdc842b15398/add.png)
Pressing this button will save the existing screen and reset it to create a new Scheduled Payment. The Scheduled Date is preset to one period after the last scheduled payment, and the amount the same as the original scheduled amount (ie. all calculated from the information in the civicrm_pledge record, we are basically extending by one installment).
UI behaviours:
- [ ] Pressing Save and New, then Cancel should not create a new scheduled payment
- [ ] Pressing Save and New, then Delete should not result in an error
Adding a scheduled pledge payment needs to augment the pledge amount by the amount of the new scheduled payment.
- Link Existing payment
In the Edit Scheduled Payment pop-up window associated with scheduled pledge payments, add a selector in order to link unmatched existing payments with this scheduled payment.
![link](/uploads/f35e26f50f5f4660602f2db553cd00c2/link.png)
The drop-down is populated with all completed, non-test payments from the same contact that are not linked to any pledge payments through the civicrm_pledge_payment table.
Each payment is displayed as: {date} {financial_type} {amount}
UI behaviours:
- [ ] When selecting a payment, protect the scheduled amount control and replace the scheduled amount with the contribution amount
- [ ] If the payment amount is not the same as the scheduled amount, then open the controls below Adjust Selected Amount and pre-select first option:
![link1](/uploads/922fbce25b325334d4fa87cd43e58379/link1.png)
- [ ] The Save action will trigger updates the same schedule / amount / adjustment updates to the civicrm_pledge_payment record, but also link with any selected payment (ie. fields contribution_id, actual_amount and status_id).
- [ ] Resetting the Link with Payment drop-down to “ -- select --” will restore the Scheduled Amount control to the initially scheduled amount and close the Adjustment controls.yashodhayashodha