bosonprotocol / widgets Goto Github PK

• connection to the widget: OK
• deliveryInfo signature (woocommerce mode): OK
• XMTP chat authentication (dApp mode): OK
• redeemVoucher meta-tx signature: NOK

An HTTP network error can be seen in the console logs:
POST https://matic-mumbai.chainstacklabs.com/ net::ERR_CONNECTION_TIMED_OUT

NOTE: it's working inside the dApp (where the web3 provider is handle by the dApp), but failing in the standalone hosted widget or in woocommerce integration

In case an exchange id is specified, the widget can directly switched to the redeem form or the exchange details or the cancellation form.
As no check is realized to be sure the connected wallet owns the selected exchange, this may lead to transaction errors.
This should be avoided (message: "you do not own this exchange")

instead of the exchange details page

As a solution, I propose:

• when connecting the wallet to the dApp, the dApp forces the widget to connect as well, so that, even if the user has to connect twice, this will happen in a sequence at the same time
• when loading the widget, the dApp sends the current connected account (if any) so that the widget can check if it's connected to the same account. If not, it forces the user to reconnect with the same account as the dApp

• when clicking Redeem on the exchange card -> Redeem the item through the widget (no step "My Items" + no step "Exchange Details")
• when clicking Cancel on the exchange card -> Cancel the item through the widget (directly to the Cancellation View)
• when clicking Redeem on the exchange details -> Redeem the item through the widget
• when clicking Cancel on the exchange details -> Cancel the item through the widget

Redemption of an exchange from offer ID 323 (testing env) is failing.
The error comes from the XMTP layer, when trying to send the message to the seller (ID 110).
The issue is not happening when committing other offers from other sellers.
It may be due to an inconsistent version of chat-sdk used by the redemption widget compared to the dApp.

Proposition:

• the partner website includes a button (should we provide styling?), when clicked show an iframe linked to the widget
• when the cross icon is clicked in the widget, the iframe is hidden and the widget is reset (to restart from the first step when shown again)

here is the PR to replicate in react-kit for the widgets
bosonprotocol/interface#944

• connect a wallet
• click Redeem
• select an exchange X
• disconnect Wallet --> the popup refresh asking to connect the wallet (OK)
• connect with another wallet --> the popup refresh on the same exchange X (that does not belongs to the new wallet) (NOK)

Instead of keeping the same exchange details page, in case the wallet has changed, reinitialize the wizard step

At the moment, the env name (testing, staging, production) shall be passed to the widget as a URL query parameter.
It should not.
We should have different widgets deployments per environment (1 testing, 1 staging, 1 production). The env name should be passed as a build env var

Change 'Initialise' button colour from green to purple

https://miro.com/app/board/uXjVMxOwJ3A=/

At the moment, the redeem widget code suggests the email to be required only when the contact preference of the seller is set to "xmtp_and_email".
If the contact preference is "xmtp", the email is asked but not required.

However, the current implementation fails in doing that in most case.
The following PR bosonprotocol/core-components#642 forces the email to be always required.

This issue is opened to raise that point and reconsider whether or not we want to achieve the initially expected behaviour

remove the content in the main page and instead do a javascript redirect to https://docs.bosonprotocol.io/docs/quick_start/widgets (this page doesnt exist yet)

the signature needs to be created by the assistant wallet, not the admin one. This is because admin wallet may be multi-sig wallets, that can't really sign a message (Gnosis Safe implements a workaround to simulate such a signature, but such a solution would require to adapt our implementation in both the widget and the WC plugin, and will complexify the user flows). In addition, future version of WC plugin with Boson Enterprise will need such a signature that will be more easily implemented with the assistant wallet (owned by BE) than the admin one.

apply changes as for bosonprotocol/interface#677

After the wallet is connected, I click Disconnect and the following error appears in the logs:

chunk-LAFZBYO7.js:642 Uncaught (in promise) Error: No wagmi config found. Ensure you have set up a config: https://wagmi.sh/react/config
    at hU (chunk-LAFZBYO7.js:642:11)
    at chunk-LAFZBYO7.js:681:19
    at useDisconnect.ts:15:11
    at Object.De (react-dom.production.min.js:54:317)
    at je (react-dom.production.min.js:54:471)
    at react-dom.production.min.js:55:35
    at Br (react-dom.production.min.js:105:68)
    at Lr (react-dom.production.min.js:106:380)
    at react-dom.production.min.js:117:104
    at cu (react-dom.production.min.js:274:42)

• When showing the widget, it must be possible to show the redemption overview (1st page) or not.
• When an exchangeId is set, it must be possible to directly show:
  • the exchange details page (then the user can select an action depending on the exchange state)
  • or, the redeem form (assuming the exchange is in Committed state)
  • or, the cancel form (assuming the exchange is in Committed state)
  • or, the redeem confirmation form (delivery info is already known and only the redeem transaction will be sent)
• When showing the list of exchanges, it must be possible to preselect:
  • committed exchanges (default behaviour)
  • or, redeemed exchanges (useful when the buyer wants to raise a dispute on an exchange)
  • or, disputed exchanges (reserve)
  • or, completed exchanges (reserve)

At the moment, there is a callback URL call when the delivery information is submitted
We need another call after the redeem transaction is submitted and another when the redeem transaction is confirmed.
In addition, we need these calls to handle the possible errors, like:

• an error occurred in the backend when the delivery info is submitted --> the widget needs to show an error occurred and shall not continue with the redemption step
• an error occurred when the transaction is submitted --> the error is sent to the backend, instead of the submitted transaction
• the transaction is reverted --> the error is sent to the backend, instead of the transaction confirmation

• https://widgets-test.on.fleek.co/#/dev: finance widget is not loading
  

• https://widgets-test.on.fleek.co/#/finance?configId=testing-80001-0: page is empty
  

• https://interface-test.on.fleek.co/#/sell/finances (assuming you're connected with a seller wallet): panel is empty
  

In all cases, the same error appears in the console

Hey team,

We've noticed that you're referencing a subgraph deployed on The Graph's hosted service in this repository. Just a heads-up: after June 12th, hosted service subgraph endpoints will no longer be available as the offering is being deprecated.

If you are the subgraph owner or maintainer, it's time to upgrade your subgraph to the network. This ensures everything keeps running smoothly and you get access to all the latest features and improvements. Here is a quick guide with all the upgrade steps.

If you're not the subgraph owner or maintainer, check Graph Explorer to see if the subgraph development team has already upgraded to the network. If you don’t find an upgraded subgraph, a friendly nudge to the subgraph development team would be greatly appreciated—it's a quick process that benefits everyone. Here's the upgrade guide with all the necessary steps for the subgraph development team.

Once the subgraph is upgraded to the network, you can create an API key and updated query URL in Subgraph Studio then update this repository to query from the new endpoint, https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>

Need more support or have more questions? Feel free to reach out to [email protected]. We're here to help!

Cheers,

Paka

Errors is raised in xmtp-js code.
Was not happening before the upgrade to XMTP v8 (#22)

same applies with REACT_APP_DEFAULT_TOKENS_LIST