Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checking for Already purchased product fails if the receiving wallet is different. #1000

Open
yondifon opened this issue Sep 22, 2024 · 6 comments
Assignees
Labels
12.x-dev backlog frozen good issue Good for newcomers question Further information is requested

Comments

@yondifon
Copy link

Describe the bug
Using $customer->paid($product)) fails when product was purchased with money transferred to another wallet.

To Reproduce
Steps to reproduce the behavior:
1.

$cart = app(Cart::class)
    ->withItem($product, receiving: $receiving)
;

$user->payCart($cart);
$user->paid($product); // returns null 

Expected behavior
The method is supposed to return true but it still return false.
It fails when it should pass (as it should though, The underlying code needs to provide a $receiving wallet

Server:

  • php version: 8.3
  • database: mysql 8.0
  • wallet version 10.1
  • cache lock: redis
  • cache wallets: redis
@yondifon yondifon added bug Something isn't working question Further information is requested labels Sep 22, 2024
@rez1dent3
Copy link
Member

Hello, @yondifon. The method has long been deprecated and this is written in phpdoc.

/**
 * Checks acquired product your wallet.
 *
 * @deprecated The method is slow and will be removed in the future
 * @see PurchaseServiceInterface
 */

The method was deprecated when the receiving purchases functionality was added.

Now you need to do this.

$transfers = app(PurchaseServiceInterface::class)->already($user, $cart->getBasketDto());

Confirmation of purchases is the amount of transfers equal to the number of items in the basket.

@rez1dent3 rez1dent3 removed the bug Something isn't working label Sep 23, 2024
@rez1dent3
Copy link
Member

In general, the current implementation is a crutch that I was strongly asked to add to the package. It does not normally take into account the return and check of the purchase of goods when transferring $receiving, since the architecture was originally different.

A separate table for orders has been requested for a long time. Most likely, this will not be earlier than v12.0. We need to come up with a new structure so as not to break the current code, which is used by many projects.

@yondifon
Copy link
Author

alright. make sense.

thanks for the clarification. (need some extra hands any time, just let me know)

@mokhosh
Copy link

mokhosh commented Oct 14, 2024

@rez1dent3 you say we should do this:

$transfers = app(PurchaseServiceInterface::class)->already($user, $cart->getBasketDto());

but in the original paid method this is what's being done, and it says it's slow and that's why it's deprecated, right?

Am I missing something here?

@rez1dent3
Copy link
Member

@mokhosh Hello. The difference is that the current paid method does not accept the $receiving wallet under the contract:

// Retrieve the cart with the given product.
// The withItem method adds the given product to the cart.
$cart = app(Cart::class)->withItem($product);

This was my first thought, then I went to double-check the code and discovered that for it to work properly, a new table was needed, which needed to be developed and added within the 12.x version.

Now, unfortunately, when setting the wallet for item, some of the functionality will not work, yes, because there is not enough data.

If you have a separate table with purchased goods, then you can override PurchaseServiceInterface and implement your logic there. Or wait for laravel-wallet 12.0, which will have this functionality out of the box. The release will be after the release of laravel 12.

@mokhosh
Copy link

mokhosh commented Oct 14, 2024

Makes sense. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
12.x-dev backlog frozen good issue Good for newcomers question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants