jamie (0b93b7f8) at 22 Mar 16:12
ensure total amount is zeroed out when selected
jamie (a53ea88e) at 20 Mar 21:30
ensure previous functionality works - click in other amount selects...
... and 1 more commit
If you set a custom default search profile via Adminster -> Customize Data and Screens -> Search Preferences
and then do a "quick search" (a search via the magnifying glass field in the top left), the results are mis-aligned with the header (and don't actually reflect the fields in the default profile):
Also, the default profile is not displayed in the "Views for Display Contacts" field if you edit the search criteria, so I think somehow the default search profile is not being communicated between the quick search and the advanced search display.
I tried to figure out what was going on but got a bit lost. I do suspect, however, that is is a regression from 390820a1bd90c9be51ca8f236cecdebfbefc8342. Do you have any thoughs @eileen?
Thank you!
@eileen @colemanw We noticed the problem when upgrading from 5.63 to 5.69. I don't think it's using the search kit rewrite because the edit search bar opens it up in advanced search, so maybe this is fixed in 5.70?
I think part of the problem is that the custom search profile feature was designed for advanced search not quick search, but since advanced search was used to display the results it gets complicated.
In any event, either it's fixed with the search kit rewrite of quick search or it's just not that important so we can move away from the feature.
Thanks for responding!
and yeah, it is a bit kooky. I think we can move away from that feature so I'll close this bug.
Also
If you set a custom default search profile via Adminster -> Customize Data and Screens -> Search Preferences
and then do a "quick search" (a search via the magnifying glass field in the top left), the results are mis-aligned with the header (and don't actually reflect the fields in the default profile):
Also, the default profile is not displayed in the "Views for Display Contacts" field if you edit the search criteria, so I think somehow the default search profile is not being communicated between the quick search and the advanced search display.
I tried to figure out what was going on but got a bit lost. I do suspect, however, that is is a regression from 390820a1bd90c9be51ca8f236cecdebfbefc8342. Do you have any thoughs @eileen?
Thank you!
jamie (688a2c8c) at 11 Mar 15:12
bump version
jamie (688a2c8c) at 11 Mar 15:12
bump version
jamie (6b355bee) at 11 Mar 15:11
update version to ensure we match change in core on replyTo header
jamie (ac522b66) at 11 Mar 15:09
this seems to be how core wants replyTo headers
The problem I'm having is totally different and an extra fee bug.
As for this particular issue, the code base has changed a lot since this issue was raised, but I think this line includes the toFixed(2)
method which I believe resolves this issue.
@mmyriam Does that seem right to you?
We may be hitting this problem as well when the extrafee extension is enabled and used.
After reading #5064, I'm not sure our experience is all that helpful! Or, maybe I should say I think there are two very distinct use cases:
I think #5064 is probably more geared towards number 2 - or will be more successful if geared towards number 2. After having pursued number 1, I have come to the conclusion that docker is not the right technology for it.
When pursuing number 2, I think it makes sense to bundle everything together: nginx, php, mysql for simplicity. But then I become curious about performance - especially if you lack control over the hardware. When we started our CiviCRM farm approach, we had one docker container for PHP per site and also one docker container per MySQL instance per site. That way each site got their own dedicated MySQL docker image - which meant if they some how borked it with hung queries it wouldn't affect anyone else. But eventually we learned that MySQL performs much better with one instance and huge amounts of RAM. Also, with everything bundled together it's harder to understand bottle necks and debug performance problems.
We use docker in production, although I'm starting to plan a switch to php-fpm. I've come to the conclusion that the relative benefits of isolation that comes from using docker vs php-fpm are minimal compared to the extra overhead and complexity. We may be a unique use case - since we own our own hardware and run all sites on the same servers (as opposed to groups that manage sites in multiple locations, in which docker provides a consistent environment).
Having said that, we have not had any significant problems with using docker in production over the last 9 years - it's worked quite well. I just made are docker files available here if you'd like to explore. We run nginx on the docker host for all docker sites on that host and we run MySQL on a dedicated virtual machine accessible via a private IP address. That allows us to create a docker image that only runs PHP for each individual CiviCRM instance we manage.
We also have a common "platform" directory on the host that provides the root web directory for each individual CiviCRM instance and we mount that directory over /var/www/html/powerbase
on each docker instance. That includes everything in the public web directory. When we update this directory on the host, all updated files are immediately available in each CiviCRM instance.
And, we also maintain separate directories for each site on the host that are mounted over sites/default
in each docker instance. That's how each site maintains it's own database connections, files, etc.
The entire setup was designed in 2015 or so, meaning we are not using anything modern or new - it's all 9 year old docker technology so there are probably ways it could be improved.
jamie (962f36a4) at 28 Feb 20:32
avoid php8.2 deprecation warnings
jamie (42b017ee) at 12 Feb 14:35
ensure district job contact_ids field is big enough for large groups
jamie (9a7b23fd) at 09 Feb 14:19
It seems that stripe will send a notice that a subscription is "unpaid" when it gives up trying to collect on it.
I'm wondering if this is a bug or a feature request? I think it's a bug, but if this is not yet implemented let me know. We'd be happy to help get this working.
I'm seeing the payment processor web hook reports:
Payment Processor: Stripe (Live ID: 1)
Status: This event was successfully processed.
Identifier: :::sub_xxxxxxx Type: customer.subscription.updated
Full message:
doCustomerSubscriptionUpdated: ignoring - not implemented
The JSON data provided by stripe includes:
Stripe\StripeObject JSON: {
"object": {
"id": "sub_xxxxxxx",
"object": "subscription",
"application": null,
"application_fee_percent": null,
"automatic_tax": {
"enabled": false,
"liability": null
},
"billing_cycle_anchor": 1626378828,
"billing_cycle_anchor_config": null,
"billing_thresholds": null,
"cancel_at": null,
"cancel_at_period_end": false,
"canceled_at": null,
"cancellation_details": {
"comment": null,
"feedback": null,
"reason": null
},
"collection_method": "charge_automatically",
"created": 1626378828,
"currency": "usd",
"current_period_end": 1708026828,
"current_period_start": 1705348428,
"customer": "cus_xxxxxE",
"days_until_due": null,
"default_payment_method": "pm_xxxxx",
"default_source": null,
"default_tax_rates": [],
"description": null,
"discount": null,
"ended_at": null,
"invoice_settings": {
"account_tax_ids": null,
"issuer": {
"type": "self"
}
},
"items": {
"object": "list",
"data": [
{
"id": "si_xxxxx",
"object": "subscription_item",
"billing_thresholds": null,
"created": 1626378828,
"metadata": [],
"plan": {
"id": "every-1-month-2500-usd",
"object": "plan",
"active": true,
"aggregate_usage": null,
"amount": 2500,
"amount_decimal": "2500",
"billing_scheme": "per_unit",
"created": 1559605475,
"currency": "usd",
"interval": "month",
"interval_count": 1,
"livemode": true,
"metadata": [],
"nickname": null,
"product": "prod_xxxxxx",
"tiers": null,
"tiers_mode": null,
"transform_usage": null,
"trial_period_days": null,
"usage_type": "licensed"
},
"price": {
"id": "every-1-month-2500-usd",
"object": "price",
"active": true,
"billing_scheme": "per_unit",
"created": 1559605475,
"currency": "usd",
"custom_unit_amount": null,
"livemode": true,
"lookup_key": null,
"metadata": [],
"nickname": null,
"product": "prod_xxxxxx",
"recurring": {
"aggregate_usage": null,
"interval": "month",
"interval_count": 1,
"trial_period_days": null,
"usage_type": "licensed"
},
"tax_behavior": "unspecified",
"tiers_mode": null,
"transform_quantity": null,
"type": "recurring",
"unit_amount": 2500,
"unit_amount_decimal": "2500"
},
"quantity": 1,
"subscription": "sub_xxxxx",
"tax_rates": []
}
],
"has_more": false,
"total_count": 1,
"url": "\/v1\/subscription_items?subscription=sub_xxxxxx"
},
"latest_invoice": "in_xxxxx",
"livemode": true,
"metadata": {
"Description": "Join xxxxx Solidarity Circle"
},
"next_pending_invoice_item_invoice": null,
"on_behalf_of": null,
"pause_collection": null,
"payment_settings": {
"payment_method_options": null,
"payment_method_types": null,
"save_default_payment_method": null
},
"pending_invoice_item_interval": null,
"pending_setup_intent": null,
"pending_update": null,
"plan": {
"id": "every-1-month-2500-usd",
"object": "plan",
"active": true,
"aggregate_usage": null,
"amount": 2500,
"amount_decimal": "2500",
"billing_scheme": "per_unit",
"created": 1559605475,
"currency": "usd",
"interval": "month",
"interval_count": 1,
"livemode": true,
"metadata": [],
"nickname": null,
"product": "prod_xxxxx",
"tiers": null,
"tiers_mode": null,
"transform_usage": null,
"trial_period_days": null,
"usage_type": "licensed"
},
"quantity": 1,
"schedule": null,
"start_date": 1626378828,
"status": "unpaid",
"tax_percent": null,
"test_clock": null,
"transfer_data": null,
"trial_end": null,
"trial_settings": {
"end_behavior": {
"missing_payment_method": "create_invoice"
}
},
"trial_start": null
},
"previous_attributes": {
"status": "past_due"
}
}