🇮🇳India @vipin.j

Address validation patch for release ^2.0 with REST API support. In order to make this patch work as expected, One need to add "Address Validation API" in both Test and Production configurations at FedEx API project.

vipin.j → created an issue.

vipin.j → created an issue.

Re rolling patch #39 for Commerce Core '3.0.x' compatibility.

vipin.j → made their first commit to this issue’s fork.

Here is the updated patch from the reference of #36, after the changes introduced & committed from #38 into Commerce Core.

@zaporylie, The current available offer plugins have limitation that a site administrator cannot restrict its users to redeem a coupon with percentage discount to a fixed quantity for an order item in checkout.

For example; suppose you got a coupon with 100% discount for a product variation. now, the site admin expects this coupon to redeem only for 1N quantity for the same order item. but, in fact with 100% discount you can even buy 10N quantity of that and place an order, and the system won't blocks you. Also, we can not go with the "Fixed amount off..." offer plugin too, because the product price may change after the coupon has been bought by the customer. The same conversation we had in #slack discussion

unset($form['display_inclusive']);: This was done because if you calculates a certain percentage of discount with a given coupon, and then update the unit price of the order item in the order checkout, then in practically that doesn't make sense with quantity validation. as the unit price has now been updated to the discounted amount and if you block that amount for say 1N quantity, then the rest of the quantity will also get multiplied by the same amount. So, basically with a configured number of quantity validation when a coupon gets redeemed than the calculated discount must only be applied to that quantity only and the rest of the quantity should then multiplied to the original unit price.

'#max' => 1000,: We just kept it to the max number, because with our use case a teacher can buy 100 coupons too for a digital product, that's it.

vipin.j → created an issue.

jsacksick → credited vipin.j → .

Closing the issue queue, as the problem was at Commerce Core end and not Mail Login, which is fixed.

@ananya.k the patch from #4 might work, but it's not recommended approach. As with Drupal Core 11 release the interface UserAuthInterface is gonna marked as deprecated, and you are reusing UserAuthInterface by replacing the recommended interface UserAuthenticationInterface. That means, you're just providing a solution by going backward, which doesn't make sense.

@see https://www.drupal.org/project/drupal/issues/3427298 📌 [11.1] Deprecate UserAuthInterface Active

The issue was Mail Login compatibility with Commerce Checkout. Eventually that problem is fixed with the Commerce Core issue queue #3464144 📌 Replace UserAuthInterface with UserAuthenticationInterface for Drupal 11 Support Fixed , but since this fix is applicable to Commerce Core release 3.x only, which is still no released yet. We still can not upgrade Mail Login to ^4.0, and if we already migrated Drupal Core to ^10.3 release, now we have to be on Mail Login 3.0.0. Because to migrate on 3.0.1, Drupal Core must be <10.3 because of the constraint ^9.1 || ^10,<10.3

If you are using Commerce Core 8.x-2.39 release with Drupal Core ^10.3, you can either be on Mail Login: 3.0.0 or you can just apply the patch #11 📌 Replace UserAuthInterface with UserAuthenticationInterface for Drupal 11 Support Fixed to Commerce Core 8.x and then you'll be able to migrate to Mail Login: ^4.0

For members who already upgraded Drupal Core to ^10.3 and wanted to update Mail Login to ^4.0.

here is the Commerce Core 8.x-2.39 compatible patch for this issue queue.

Yes, the version 4.0.1 conflicts with Commerce Core: 2.39 and failed the drush site installation.

vipin.j → created an issue.

#45 worked, Thanks.

Re-rolling patch from #34 for release commerce 8.x-2.39

Done.

This patch provides a Commerce Authnet payment gateway plugin from Authorize.net "Accept Hosted" payment gateway. The plugin is implemented with the documentation Accept Hosted. it provides all the necessary configurations required for both Authorize.net API and Commerce Payment gateway support.

Since this is the basic implementation with necessary requirements/services to be fulfilled like Performing a credit card transaction, Placing a full/partial refund request from the order UI, Maintaining Authorize.net Customer ID with Drupal user as Remote ID so the transactions, Payment methods, Shipping profiles history can be maintained over Authorize.net servers with CIM (Customer Information Management) support.

It does required implementation support for authOnlyTransaction transaction type, and also having possibilities of improvements.

vipin.j → created an issue.

The documentation provided by Authorize.net for Accept.js implementation prefers & recommend to perform a createTransactionRequest with the one-time-use token, or payment nonce received in exchange of payment data submitted.

We have referred a sample code for Drupal to implement Accept.js with createTransactionRequest, from the Sample Application on GitHub provided by Authorize.net and, experienced that when we build a transaction request with createTransactionRequest from the payment nonce received, we had no error/failure with the transaction, even when the Card Code(CVV) field was set to required or not with the Authorize.net merchant account. in both cases our transaction request executed successfully.

But when we preferred to create Customer Profiles first over transaction request i.e. Customer Profile and Payment profile to charge the customer credit card, which Commerce Authnet's Accept.js plugin doing currently, we face the error message as "Card Code Required", when we set the Card Code field to required with Authorize.net merchant account's "Payment Form - Fields" settings.

We can achieve security of the payment transaction while setting up the "Card Code" field to required, when we update the Accept.js plugin to perform a createTransactionRequest first over the creation of Customer Profile and Payment Profile.

Though we can fetch Customer ID and Payment Profile ID from the transId reference with a new request createCustomerProfileFromTransactionRequest and this transId returned as a response of createTransactionRequest.

But we need to accept that, whether we create profiles from Payment Nonce received or from the transId, The transaction request with reference to Profiles will always end-up with "Card Code is required." when Card Code field is set to required.

Re-rolling the patch #4 as it started failing after the recent release 1.2.0.

From patch #6 we are carrying a deprecated statement which has fixed with the issue #3336658 📌 PHP 8.2: ${var} in strings is deprecated Fixed

Re-rolling patch #24 to fix this issue in the patch.

Choosing approach #1 for this validation. The class method \Drupal\commerce\Plugin\Derivative\InboxLocalAction::getDerivativeDefinitions() is validated same as commerce_toolbar() against the setting commerce_dashboard_show_toolbar_link.

The attachment field cardinality is set to unlimited now.

Patch #3 started failing on recent release 8.x-1.3

The patch rerolled.

#14 and #15 patches were badly edited for test case requirement for plugin "Flat Rate + Per Item" which cause testbot failure.
here is the updated patch with a separate test case for "Flat Rate + Per Item".

@sdsc, I'm not the maintainer of Commerce Shipping but just a Drupal community contributor. including the patch in releases is totally in module maintainer's choice.

Yeah, but you can use Composer Patches plugin to update your code with recent patches available to issues queues.

Re-rolling patch #14 for compatibility with 8.x-2.7

Re-rolled patch #11 with failing test case fixes and improvements.

@Morbus Iff, The issue mentioned with comment #4 was belongs to the patch submitted with issue queue #3019539 ✨ Expand Accept.js to include Accept.js UI Needs review

Since, the patch was developed in context of Authorize.net (Accept.js UI) API, which accepts expiry_year in format of YY, while the Commerce Payment stores that value in YYYY format. which creates conflict on Payment Method edit, that the default year won't get select as expected.

The bug was fixed with the most recent patch update #38 ✨ Expand Accept.js to include Accept.js UI Needs review

we can close this issue now.

I've updated patch #37 in order to fix a bug with this patch.

to reproduce:

1. Head to user/#/payment-methods
2. Create a new payment method with Authorize.net (Accept.js UI)
3. On success, edit this newly created payment method.
4. Regardless of what YEAR you have specified (while adding the payment method), the year on the saved payment method will always show the first item in the select dropdown (in this case: 23).

The old patch overrides Commerce Payment's default expected expiry year storage format i.e. YYYY to YY. so, the payment methods created by Authorize.net (Accept.js UI) gateway will store year in YY format instead of YYYY. This because the Accept.js UI form allows YY for the expiration year, and that value followed in the whole processing of validation and storing to database.

The patch #2 re-rolled with improvements.

We have exposed Commerce License events to Commerce Email's "Add email" event list. now users can create Email events on Commerce license's events.

Here is the patch for the requirement of this issue, hopefully it will help.

vipin.j → created an issue.

Small tweak in the patch to remove one of the WCAG 2.1 issue.

Fixing failed test cases.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here is the patch to update missing details.

vipin.j → created an issue.

Patch #192 was fixed for failure while patch application, due to test case file changes DefaultsSectionStorageTest.php, in RC1 release. This patch is applicable for version 10.1.x-dev.

Patch #7 re-rolled for version 3.0.x-dev.

The patch #18 is re-rolled with updates for release ^2.35 compatibility.

This patch will create an unordered list of mail attachments on a mail log view, if that email has attachments.
hope this will be helpful.

This merge request was missing Drupal 10 migration support in composer.json file, which further affects building dependencies in site's composer.lock. which means currently in site's composer.lock the require is still lock to D8 & D9, i.e. "drupal/core": "^8 || ^9".

So, to migrate from existing Drupal 9 site to Drupal 10, it should also be compatible with ^10, which can be managed by module's composer.json.

with #7 commits, now the generated .diff file is failing with composer-patches on release version 8.x-1.1, because of the # Information added by Drupal.org packaging script on 2020-06-23 details in commerce_checkout_order_fields.info.yml, conflicts with the changes done by the commits.

I have tried to fix the composer patch application failure with this patch. this will help in removal of conflict with dependencies and the last commits. We still wait for the merge request to be approved for next stable D10 release.

vipin.j → made their first commit to this issue’s fork.

vipin.j → made their first commit to this issue’s fork.

vipin.j → made their first commit to this issue’s fork.

This patch will add Drupal 10 and PHP 8.1 support. the FedEx API has been replaced from NicholasCreativeMedia/FedExPHP to JeremyDunn/php-fedex-api-wrapper → with this patch.

vipin.j → created an issue.

Rerolling this patch based on #81 for 2.0.x compatibility.