What would it take to implement this as Jon suggested? Whose call? And "if easy" what funding, if any needed? Remove a SalesForce advantage which has been a show stopper for a couple of prospects for Civi.
Not sure if this is a directly related issue but a client was told by Stripe that they needed to have their "integrator" support automatic checkout vs manual to avoid duplicate authorizations for the same debit card transaction. This information was passed along second hand. Does this seem like a Stripe checkout support issue? Perhaps we can help support the work if it is more broadly useful.
I was evaluating sales force a few years back and encrypting specific fields was the only feature that Civi could not match. Propose adding that to the ACL project.
The other feature - unrelated I guess - is the ability to encrypt a custom field at rest. Much like the password fields. Where might that fit in the big picture?
Am I correct thinking that this would be useful for protecting specific data in a HIPPA application?
I'll put $500 towards it
Have what seems to be this exact issue - the error and the incomplete transaction result. Detailed it on stackexchange - https://civicrm.stackexchange.com/questions/42878/civi-error-using-d9-webform-for-contribution-payments-unable-to-complete-payme
I am having a terrible time setting up AWS bounce processing with multiple strange errors that seem to revolve around the bounce account setup. With no bounce account, the AWS bounces work but then Civi Test option does not work. I would be willing to contribute to implementing this.
Any ideas on how to avoid it getting into this state?
Have tested the PR. The conflicting entity error is no longer there, replaced by "DB Error: no such field". The partial upgrade problem continues at the same failure version. Can the PR be modified to also bypass the no such field error?
I have looked at the databases for instances that show the no such field error and the fields referenced are not there. Version 5.45.7 (ESR) has these fields in the database. They are gone somewhere after that and the no such field error causes a halt to the upgrade. Is there a way to change these so that if they are missing, the upgrade process continues?
5.48.beta1.mysql.tpl 383 bytes 1 2 3 4 5 6 7 {* file to handle db changes in 5.48.beta1 during upgrade *} -- Remove entry for Grant Reports since grant is not a component anymore so this url just shows an empty list DELETE FROM civicrm_navigation WHERE url='civicrm/report/list?compid=5&reset=1'; DELETE FROM civicrm_managed WHERE module = "civigrant" AND entity_type = "OptionValue" AND name LIKE "OptionGroup_grant_type_%";
civicrm_queue for partial db upgrade is empty.
I have consistently had this problem using entirely different client instances which seems to discount the failed prior upgrade cause. (These instances fail each time they are run.) Would it help to check if the civicrm_queue table exists. And same question for auto_run field? If so, where should I find them?
Is there a theory as to why the db upgrade fails when it gets to this entry? Seems that the upgrade process needs to catch this problem? Or somehow avoid it? 5.48.beta1.mysql.tpl 383 bytes 1 2 3 4 5 6 7 {* file to handle db changes in 5.48.beta1 during upgrade *} -- Remove entry for Grant Reports since grant is not a component anymore so this url just shows an empty list DELETE FROM civicrm_navigation WHERE url='civicrm/report/list?compid=5&reset=1'; DELETE FROM civicrm_managed WHERE module = "civigrant" AND entity_type = "OptionValue" AND name LIKE "OptionGroup_grant_type_%";
The database is a 5.45 ESR version. Not sure about dropping. I did not create the process but will check with the developer.
No luck with the PR update. Same partial database upgrade with stop at this point - 5.48.alpha1.upgrade
One difference is the error is now:
2022-06-28 21:02:37,715 P3152 [INFO] In Error.php line 955:
2022-06-28 21:02:37,715 P3152 [INFO]
2022-06-28 21:02:37,715 P3152 [INFO] DB Error: no such field
OK, thanks. Hopefully later today as getting new underground cable from Comcast right now! Or as soon as I tell them to go ahead and disconnect me
Regarding the #3101 (closed) issue, we are getting this error message as part of Civi and extension upgrade process to Civi 5.50/51 that results in partial database upgrade: "error_message": "API error: Field: name
must be unique. An conflicting entity already exists - id: 105 on OptionGroup.create( entity name search_display_type)
Partial database version field shows version 5.48.alpha1.upgrade which is just prior to https://lab.civicrm.org/dev/core/-/blob/5.48/CRM/Upgrade/Incremental/sql/5.48.beta1.mysql.tpl
Feels like a rat's nest of issues crossing Extended reports, SearchKit, CiviGrant ...
actually it is a CiviGrant issue, correct?