Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-12-17T22:10:48Zhttps://lab.civicrm.org/dev/financial/-/issues/47Payment Instrument not set on Pending Contributions' payments when marked "Co...2019-12-17T22:10:48ZJonGoldPayment Instrument not set on Pending Contributions' payments when marked "Completed".There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment b...There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **More ยป Record Payment** and entering the payment.
* Click the **pencil** to edit the resulting payment. Everything looks fine.
#### Scenario 2
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **Edit** and changing the contribution status to **Completed**.
* Click the **pencil** to edit the resulting payment. The payment instrument is blank. Moreover, any attempt to change the payment instrument results in a fatal error (similar to core#264). See below.
The backtrace below seems like a symptom of the root cause, which is in the second step (changing the contribution status) not the third step.
```
CiviCRM_API3_Exception: "Mandatory key(s) missing from params array: payment_instrument_id"
#0 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(213): civicrm_api3("FinancialTrxn", "create", (Array:9))
#1 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(181): CRM_Financial_Form_PaymentEdit->submit((Array:5))
#2 /example.org/sites/all/modules/civicrm/CRM/Core/Form.php(489): CRM_Financial_Form_PaymentEdit->postProcess()
#3 /example.org/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Submit.php(74): CRM_Core_Form->mainProcess()
#4 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Submit->perform(Object(CRM_Financial_Form_PaymentEdit), "submit")
#5 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Financial_Form_PaymentEdit), "submit")
#6 /example.org/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("submit")
#7 /example.org/sites/all/modules/civicrm/CRM/Utils/Wrapper.php(113): CRM_Core_Controller->run()
#8 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(283): CRM_Utils_Wrapper->run("CRM_Financial_Form_PaymentEdit", NULL, NULL)
#9 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:14))
#10 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#11 /example.org/sites/all/modules/civicrm/drupal/civicrm.module(345): CRM_Core_Invoke::invoke((Array:3))
#12 [internal function](): civicrm_invoke("payment", "edit")
#13 /example.org/includes/menu.inc(350): call_user_func_array("civicrm_invoke", (Array:2))
#14 /example.org/index.php(22): menu_execute_active_handler()
#15 {main}
```https://lab.civicrm.org/dev/release/-/issues/10Security Releases - Update post-release communications workflow2019-11-27T23:11:00ZtottenSecurity Releases - Update post-release communications workflow__Synopsis__: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consis...__Synopsis__: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consistency.
__Target Media__:
The communications about a recent release may hit the following media:
* `chat.civicrm.org` (public groups) - "Town square", "dev", "product-maintenance"
* `chat.civicrm.org` (private groups) - "security", "ESR", "mergers"
* `latest.civicrm.org` - Versions listing (which feeds `civicrm.org/download` and in-app notices)
* `sourceforge.net` - Default download
* `civicrm.org` - Security advisories
* `civicrm.org` - Blog
* `civicrm.org` - "Security Notifications" mailing list
* `twitter.com` - `@civicrm` account
* `facebook.com` - CiviCRM group
__Considerations__:
* The broad communications for monthly-releases and security-releases are similar, but security-releases have the higher bar because they are more urgent, leading to more time-sensitivity and a longer list of media. Consequently, if we solve security-releases, then our monthly-releases can follow a simpler subset of the workflow.
* The list of media has tended to grow over time.
* The people who post to each medium has varied overtime.
* The knowledge/access of posting in different media are spread among different people.
* The best documents to refer people to are generally (a) the blog article and/or (b) the release-notes.
* The document [any-announce.md](https://lab.civicrm.org/dev/release/blob/master/doc/any-announce.md) proscribes some particular steps. It is slightly out-of-date, and includes a range of tasks which have (for at least... 5 years?) been split among different people.
* Today, the emotional experience of getting announcements is a bit like this: *You sign up for 3 channels, and then you don't see a notice on whichever one is your favorite, and someone tells you that you need to signup for more.*
* Today, the emotional experience of sending announcements is a bit like this: *You post a message to 5 channels, and then someone says that you didn't post to a 6th channel that you don't personally use.*
* It is conceivable to use a smaller list of feeds (like `latest.civicrm.org` and `release-notes`) to populate more channels automatically. This would require case-by-case technical implementation. Alternatively, for media where automation has poor cost/benefit, we can have a person responsible for each medium. This would likely create some lag (b/c it's hard to precisely coordinate timing across multiple continents). Any style of contribution (*automating a medium or standing sentry for a medium*) is useful.
__Proposal :one:__:
1. Team organization
1. There is a private MM group for people involved with release communications.
2. Rename the current `mergers` group to `releasers` or `release-team` or somesuch -- since this is a more accurate reflection of how the group works.
3. In the the GL project `dev/release`, add a wiki page with a list of media and the party responsible for each medium. Anyone added to this list must also be added to MM.
4. The MM channel has sticky link at the top to the wiki page.
2. For post-release communications, the workflow goes as follows:
1. Tarball and tag information goes up to `download.civicrm.org`, `sf.net`, `latest.civicrm.org`. The release is live.
2. The person who uploads then sends a notification to all `releasers` that the release is live.
3. Each person who signed up for release-comm's gets the ping and does thing their thing.
__Meta__
* If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
* Related: [Security Releases - Update pre-release communications workflow](https://lab.civicrm.org/dev/release/issues/11)https://lab.civicrm.org/dev/financial/-/issues/108Disabling a price option or price field causes to be zeroed out and financial...2019-11-19T09:22:41ZseamusleeDisabling a price option or price field causes to be zeroed out and financial integrity issues when changing fee selectionsTo reproduce this error:
1. Create a Price set with > 1 price fields
2. Register and pay for someone using just 1 of those price fields
3. Now disable the price field that was used in step 2
4. Navigate to change fee selections to now s...To reproduce this error:
1. Create a Price set with > 1 price fields
2. Register and pay for someone using just 1 of those price fields
3. Now disable the price field that was used in step 2
4. Navigate to change fee selections to now select an option from the 2nd price field
5. Notice that the qty for the first price field gets zeroed out and no new financial trxn is created sensibly.
I believe @KarinG replicated this in chat https://chat.civicrm.org/civicrm/pl/ap5bif4gsifeuc57yftbxnmynh a work around is to rather than disabling the price option is to set the visibility to be admin only. The situation we were having is we were offering a catered option and an uncatered option for an event and wanted to stop people registering for the catered option at a point in time.https://lab.civicrm.org/dev/drupal/-/issues/81Drupal8: Large export results in logout2019-11-03T16:19:27ZJonGoldDrupal8: Large export results in logoutWhen you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces,...When you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces, more readable:
```
Warning: session_start(): Failed to decode session object. Session has been destroyed in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 149 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#1 [internal function]: _drupal_error_handler(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php(149): session_start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#5 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#6 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#15 {main}.
```
```
RuntimeException: Failed to start the session in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 150 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#6 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#12 {main}.
```
The first issue is a warning that the session is too large, and so it destroys the session (which causes a logout). The second issue is of "error" severity saying the session can't be found.
Here's someone else having a similar issue in Symfony (not Drupal8): https://github.com/symfony/symfony/issues/26623tottentottenhttps://lab.civicrm.org/dev/financial/-/issues/81Update Contribution Payment Instrument Id to match first payment when the st...2019-11-01T20:59:49ZeileenUpdate Contribution Payment Instrument Id to match first payment when the status is PendingIf we are asking people to create a pending Order they may not know the payment instrument at that time. We should adjust Payment.Create to update it when a payment comes in & it is the first one.
(Alternatively we could always update ...If we are asking people to create a pending Order they may not know the payment instrument at that time. We should adjust Payment.Create to update it when a payment comes in & it is the first one.
(Alternatively we could always update it so it becomes the latest - probably an edge case)https://lab.civicrm.org/dev/financial/-/issues/83Barcelona sprint financials2019-11-01T12:05:38ZeileenBarcelona sprint financialsI'm creating this issue to document & track the discussions we had at the Barcelona sprint.
We had a financial team of @mattwire @JoeMurray @ayduns @artfulrobot @BjoernE @andrei @ejegg present
Main issues
1. Ensuring there were ...I'm creating this issue to document & track the discussions we had at the Barcelona sprint.
We had a financial team of @mattwire @JoeMurray @ayduns @artfulrobot @BjoernE @andrei @ejegg present
Main issues
1. Ensuring there were no blockers to people using the Order.create->PaymentProcessor.pay->Payment.create flow https://lab.civicrm.org/dev/financial/issues/76
1. Making the poor performance associated with the creditnote_id field opt in rather than opt out https://lab.civicrm.org/dev/financial/issues/84
1. Addressing Stripe's need to store some Stripe generated information for which there is no suitable field. We resolved this at the data level by adding the field civicrm_financial_trxn.result_code. However docs pending! https://lab.civicrm.org/dev/financial/issues/57
1. Having a plan to get off our broken contribution.template model https://lab.civicrm.org/dev/financial/issues/6
1. UI for permitting refunds processing for payments. https://lab.civicrm.org/dev/financial/issues/85
Not actually from the sprint but topical from discussions - add getters & setters to payment processor base class https://lab.civicrm.org/dev/financial/issues/82https://lab.civicrm.org/dev/financial/-/issues/92Change signature of CRM_Core_Payment::doRefund(&$params) to not receive $para...2019-11-01T12:04:35ZeileenChange signature of CRM_Core_Payment::doRefund(&$params) to not receive $params as a referenceThis is a proposal by @mattwire which is mostly stylistic
pros - we have been moving away from receiving as reference
- less scope for people to try to achieve odd things in there
cons - less consistent with doPayment
- would...This is a proposal by @mattwire which is mostly stylistic
pros - we have been moving away from receiving as reference
- less scope for people to try to achieve odd things in there
cons - less consistent with doPayment
- would need to do a civi universe or whatever that things is of Tims to find what processors might need to be patched to cope
- less opportunity for payment processors to tweak thingshttps://lab.civicrm.org/dev/financial/-/issues/95Update Payment.create api handling of payment instrument2019-11-01T12:04:03ZeileenUpdate Payment.create api handling of payment instrumentAt the moment the passed in payment_instrument_id will take precedent over the one associated with the relevant processor. I don't think that is how the design was intended and in other places we use the paymnet_processor_id.
Note that...At the moment the passed in payment_instrument_id will take precedent over the one associated with the relevant processor. I don't think that is how the design was intended and in other places we use the paymnet_processor_id.
Note that I think that the Payment.create api should require either the payment_instrument_id or the payment_processor_id.
Logically this is something 'known' when making a payment & not something we should 'guess'. Transitionally we would deprecate NOT passing in one of those values rathe than requiring it.
I do think we should add some handling to Order.create so that specifically when chaining Payment.create it automatically sets some values - this being one.
@JoeMurray @monish.deb @artfulrobothttps://lab.civicrm.org/dev/financial/-/issues/93Agree / implement handling of failure for doPayment/ doRefund / params for do...2019-11-01T11:58:47ZeileenAgree / implement handling of failure for doPayment/ doRefund / params for doRefundCurrently both doPayment and doRefund throw a PaymentProcessorException if there is a failure either in terms of config or in terms of processing. The flow we agreed back when we implemented this in 4.6 is we should be working towards
`...Currently both doPayment and doRefund throw a PaymentProcessorException if there is a failure either in terms of config or in terms of processing. The flow we agreed back when we implemented this in 4.6 is we should be working towards
```
Order.create.... status=pending
try {
$result = $paymentObject->doPayment();
if ($result['payment_status_id') === 1) {
Payment.create.....
}
}
else {
\\ Add code here to add failed payment
}
```
Currently the CRM_Core_Payment doPayment converts failed results for old processors to exceptions and throws them and new processors have been expected to throw exceptions.
Some of the forms implement things similar to the above although in other cases the exception is caught much further from the call to doPayment and in some cases we are still not creating the order before processing the payment.
Note that in this flow a payment that did not fail but was not successful would not result in a payment being created.
@mattwire is proposing that we change this for doRefund and stop throwing exceptions for failed payments (or any types) and instead return a status for failed for user-related reasons and an exception for system related reasons.
The options as I see them are
1) implement the same pattern for doRefund as doPayment
2) implement and extend the pattern - ie add a couple of things we probably would have done if implementing from scratch such as
- a PaymentProcessorException_PaymentFailed Exception which extends the existing PaymentProcessorException & can be throwing when the payment relates to card failure rather than a config error. Calling code can choose to catch these separately if it chooses. (we could use this for doPayment too)
- add a getter for the outcome ie. start a transition from returning 1 / the value that maps to contributionStatus = Completed (which is not actually a payment status) to ```$paymentObject->isCompleted()``` or ``` $paymentObject->isSuccessful()```. (Note Omnipay uses isSuccessful()). We could transition doPayment to this over time.
- add a property / getter for getRefundTrxnResult
- add a property / getter for 'processor_result' / 'passthrough_params' which is something that @mattwire has suggested although I have no specifics / examples.
- encourage the use of getters & setters rather than passing in params - ie ```$paymentObject->setAmount(20.40);``` Notte we have just added getters & setters to the class in general https://lab.civicrm.org/dev/financial/issues/82 - implement this in the api call & new core interactions with the class
3) switch to the pattern matt proposes - ie. for doRefund
```
return [
// refund_status_id would normally return the contribution_status_id Completed or Failed
'refund_status_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'contribution_status_id', 'Completed'),
// The refund trxn_id may be different from the trxn_id of the original payment.
// If it is the same then trxn_id should be copied to refund_trxn_id
'refund_trxn_id' => NULL,
// Array of params returned by the payment processor. The contents of this will vary by processor and should not be relied on.
// However, they can be very useful for logging or providing specific feedback.
'processor_result' => [],
];
```https://lab.civicrm.org/dev/financial/-/issues/91Discuss / maybe resolve schema issue on changing line items2019-10-25T22:17:31ZeileenDiscuss / maybe resolve schema issue on changing line itemsPer
https://docs.civicrm.org/dev/en/latest/financial/financialentities/
If the line items change then the items financial items have to be updated. Generally the rule is to zero-out the current line items
and reverse their financial ite...Per
https://docs.civicrm.org/dev/en/latest/financial/financialentities/
If the line items change then the items financial items have to be updated. Generally the rule is to zero-out the current line items
and reverse their financial items and create new ones. This is a pretty standard accounting approach.
Unfortunately there are some scenarios where the schema does not permit this which has resulted in
adjustment line items being created in these cases. The issue is that the civicrm_line_item table has a unique index for
entity_table + entity_id + contribution_id + price_field_value_id + price_field_id.
This means that if a line item with no price_field_values (ie a text / enter quantity line item) is altered it is not possible
to create a reversal line a new line within the schema. The same problem occurs when changing a line item with price_field_values
BACK to a price_field_value it previously held. In both these scenarios the work around is to have more than one 'valid' financial_item
against the resulting line item with an 'adjustment' entry - ie an additional financial_item.
I don't have any good answers except maybe add an 'is_current' field & add that to the index. Perhaps the current pain is unavoidable but it feels a bit like an own goal
@JoeMurray @monish.deb @lcdweb @kcristiano @pradeephttps://lab.civicrm.org/dev/financial/-/issues/90Add new api Order functionality to update line items2019-10-25T08:12:07ZeileenAdd new api Order functionality to update line itemsI'm pretty sure that despite @JoeMurray's optimism the current apiv3 Order.create doesn't support this. @monish.deb & I discussed adding it back here
https://github.com/civicrm/civicrm-core/pull/11380
I don't think we should add it o a...I'm pretty sure that despite @JoeMurray's optimism the current apiv3 Order.create doesn't support this. @monish.deb & I discussed adding it back here
https://github.com/civicrm/civicrm-core/pull/11380
I don't think we should add it o apiv3 now - I think we should write a v4 api that does it. I think the object oriented approach will allow us to come up with cleaner methods. I'm kinda keen to try to build those up on a ORDER pseudoBAO class & play a bit before we expose in the api so we can learn about about what works & doesn't before locking it inhttps://lab.civicrm.org/dev/financial/-/issues/85UI in core for processing refunds2019-10-21T21:48:01ZeileenUI in core for processing refundsWe looked at adding the ability to process refunds via the UI at the sprint.
We looked at
1) Changing the existing record refund form (Additional Payment form) to provide the option of processing the refund if offered by the processor ...We looked at adding the ability to process refunds via the UI at the sprint.
We looked at
1) Changing the existing record refund form (Additional Payment form) to provide the option of processing the refund if offered by the processor if a check box was selected
1) Changing the existing record refund form (Additional Payment form) to provide the option of processing the refund if offered by the processor if a differently named button was pressed
1) Having a second action for 'Process Refund' or similar
Opinions at Barcelona were pretty evenly divided between the 3!
A couple of things that might make a difference
1) here is a screen shot of how adding a payment currently looks
![Screen_Shot_2019-10-21_at_7.57.12_PM](/uploads/08d0eb711f4dd11fe0a980b8f92f949c/Screen_Shot_2019-10-21_at_7.57.12_PM.png)
1) @JoeMurray was keen that it be a case of the option showing if ALL payments on a contribution could be refunded. In the edge case of payments from more than one processor the submit refund option would not show
1) @JoeMurray agreed that it is OK to ALWAYS show 'record payment' & 'record refund' as opposed to currently it only shows 'add payment' if there it a balance to pay & add 'record refund' if there is a balance to refund. However, we need to be able to overpay & over refund - I'm going to work on this issue & seeing the UI afterwards (just having the links more often visible) might affect what people think 'makes sense' - issue for that is https://lab.civicrm.org/dev/financial/issues/86https://lab.civicrm.org/dev/financial/-/issues/75on order.get, line item has obsoleted contribution_type_id2019-10-19T22:49:23ZJoeMurrayon order.get, line item has obsoleted contribution_type_idThe line item table does not have a contribution_type_id. But when the results of a contribution.get are displayed, the line item fields includes both financial_type_id and contribution_type_id. This seems like an historical artifact tha...The line item table does not have a contribution_type_id. But when the results of a contribution.get are displayed, the line item fields includes both financial_type_id and contribution_type_id. This seems like an historical artifact that should be removed.https://lab.civicrm.org/dev/user-interface/-/issues/9Can't add / edit Name Badge Template Options2019-10-08T15:58:20ZHeatherOliverCan't add / edit Name Badge Template OptionsThrough the UI, you can add / edit Mailing Label format options, but not options for Event Labels. This means unless you are using one of the four pre-configured options, you need to go to the SQL to change between Mailing Label and Name...Through the UI, you can add / edit Mailing Label format options, but not options for Event Labels. This means unless you are using one of the four pre-configured options, you need to go to the SQL to change between Mailing Label and Name badge to test and use.
/civicrm/admin/labelFormats?reset=1
![mailing-labels](/uploads/9b6e6dcd428fd100daddb4aacf6aefeb/mailing-labels.PNG)https://lab.civicrm.org/dev/user-interface/-/issues/7Ability to exclude activities that appear on the actions button on a contact ...2019-10-07T13:29:15ZHeatherOliverAbility to exclude activities that appear on the actions button on a contact recordAll activity types that are added to CiviCRM are included in the Actions button when you view a contact record. For sites with a lot of activities (particularly those which are used in connection with Drupal webforms andnot normally trig...All activity types that are added to CiviCRM are included in the Actions button when you view a contact record. For sites with a lot of activities (particularly those which are used in connection with Drupal webforms andnot normally triggered in CiviCRM directly) this becomes a bit frustrating to manage.
Adding / filtering activities in other places uses the look up function, meaning the the length of the list in those places isn't really an issue.
See two attached images as an example. This isn't even all the activities for this site.
![image-1](/uploads/9b605ca4b8c666484a20ffb6be744651/image-1.PNG)![image-2](/uploads/56b30fe891eeaa9bbab310c74328cfb5/image-2.PNG)https://lab.civicrm.org/dev/user-interface/-/issues/4Enhancement - Quick search contact lookup2019-10-07T13:26:00ZrebeccatregennaEnhancement - Quick search contact lookupAllow quick search to be used with full names rather than by leading last name; e.g. allow users to search for Oliver Gibson.Allow quick search to be used with full names rather than by leading last name; e.g. allow users to search for Oliver Gibson.https://lab.civicrm.org/dev/drupal/-/issues/86Group Role sync not mapping users but duplicating users2019-09-13T07:05:05ZacaselliGroup Role sync not mapping users but duplicating usersHi,
The group role sync module doesn't seem to work properly anymore. When I create a new user and I log in for the first time, instead of mapping the Drupal user id with the civicrm user id, the module maps the drupal user id to a new ...Hi,
The group role sync module doesn't seem to work properly anymore. When I create a new user and I log in for the first time, instead of mapping the Drupal user id with the civicrm user id, the module maps the drupal user id to a new user that has everything blank apart from the email.
I checked in the database, and in the table uf_match to confirm and here is (I think) what the module does.
When a user logs in, the checking of the existing user doesn't work anymore, so a new user is created with only the email field and that new user civicrm id is mapped with the drupal id in the uf_match table.
This is causing a lot of problems in our website. I updated to the latest version, 5.17.3 but that didn't fix it either. I noticed this error since version 5.11https://lab.civicrm.org/dev/user-interface/-/issues/1Remove "Backend" from the Access CiviCRM permission label2019-08-15T06:52:49ZmarshRemove "Backend" from the Access CiviCRM permission labelon admin>people/permissions the name of Access CiviCRM has changed to "Access CiviCRM backend and API".
This is confusing for two reasons:
- backend infers something behind Civi, not Civi itself
- there are many references to Access Civ...on admin>people/permissions the name of Access CiviCRM has changed to "Access CiviCRM backend and API".
This is confusing for two reasons:
- backend infers something behind Civi, not Civi itself
- there are many references to Access CiviCRM in the notes on the page.
Would it be more prudent to change the label to "Access CiviCRM (and API)", or am I just being pedantic?https://lab.civicrm.org/dev/financial/-/issues/41PSD2 support needed for PayPal by Sept 20192019-07-22T22:24:16ZAndrew WestPSD2 support needed for PayPal by Sept 2019PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other p...PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other payment methods where Civi hosts the payment fields). In practice I think this'll mean an intermediary page after payment, where people can verify their card details.
We are happy to chip in on development of this, but we can't fund it entirely.https://lab.civicrm.org/dev/financial/-/issues/39Authorize.net doesn't support MD5 hashing at the end of the month2019-07-02T14:40:29ZJonGoldAuthorize.net doesn't support MD5 hashing at the end of the monthI just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Ex...I just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Exchange.
> Authorize.Net is phasing out the MD5 based transHash element in favor
> of the SHA-256 based transHashSHA2. The setting in the Merchant
> Interface which controls the MD5 Hash option will be removed by the
> end of January 2019, and the transHash element will stop returning
> values at a later date to be determined.
>
> Merchants utilizing this feature will need to work with their web
> developer or solutions provider to verify if they are still utilizing
> MD5 based hash and if still needed to move to SHA-256 hash via
> Signature Key.