[alexg]

Since my previous post I have identified a bug that causes the balance to momentarily seem negative, but the order is not actually placed. This particular bug does not actually allow users to purchase more coins than they should. This bug was introduced in 0.5.0-beta. However I will look at this again tomorrow.

[alexg]

Thank you.

Again, I cannot reproduce the problem. All my tests show that everything is fine, as with the other problem you reported earlier (market creation). When I set the fee to zero, no fees are applied, and when I select the max amount to transact, this works for me.

Something is very strange and I have to think of how to debug it. I am not sure right now what other information to ask you, once I do I will get back to you.

[alexg]

Thanks for reporting.

This sounds worrying.

However, I cannot reproduce the problem and there is nothing in the latest update (from 0.5.1-beta to 0.5.2-beta) that has to do with balance checks. Moreover, if you were to get any error message on order placement, the whole DB transaction would roll back and no order would be placed. So something is very strange here.

Could you please guide me so I can reproduce your steps? It’s best if I use the exact numbers that you used to test. Also, can you check your transactions in the admin screens to verify that the order was executed?

thank you

[alexg]

Hello,

There is no shortcode to display the fees.

The maker and taker fee percentages are in the following JavaScript fields:

walletsExchangeUserData.makerFee
walletsExchangeUserData.takerFee

So you can use these to display fees. The amounts that the user enters into the limit buy / limit sell forms are in wp.wallets.viewModels.walletsExchange.exchangeBuyAmount() and wp.wallets.viewModels.walletsExchange.exchangeSellAmount(). So you could do the multiplication and display fees.

But until the order is executed, you do not know how much of it is going to be charged with maker fees and how much with taker fees. For that you would have to run the algorithm through a snapshot of the order book. So it is much easier to give a low and a high estimate for the fees.

Hope this helps.

with regards

[alexg]

Oops the option does not get written on multisite. I will fix that in the next patch of the parent plugin.

I am still unable to determine why you would be unable to view the market. From all the clues you’ve given me it seems that you are able to add it correctly to your database, but the JSON API does not report it to the frontend.

Very strange indeed.

[alexg]

I’m very glad you were able to resolve the issue.

And looking at the problem as a learning opportunity is a very positive thing to do!

with regards

[alexg]

Hello,

For the duration that the coin adapter was not running, your website was not accepting IPN messages for any deposits. The funds for these deposits are in the CoinPayments wallet as always, but the plugin doesn’t know about them. The CoinPayments platform would have attempted a few times to resend the messages, and then some of these would have been marked as failed permanently to get delivered. All you have to do is log in to your CoinPayments platform, find out which IPNs were not delivered, and resend them. Then all deposits will be accounted for in the plugin.

Do not worry about accidentally re-sending messages that were already sent and accepted, they will not be counted twice because each deposit has a unique ID.

with regards

[alexg]

Thank you.

There is no need, I can see it in my dev environment.

I will add your request to the backlog.

with regards

[alexg]

Yes, you can.

[alexg]

There is no such functionality at the moment.

However, I do plan to provide this functionality in the form of an extension.

I will let you know here when I do.

[alexg]

Hello,

I have moved your post to the general discussion as it is not related to the coin adapter.

This bug was introduced in 3.9.0 and was fixed in 3.9.2. Could you please check that you are running the latest version of the parent plugin?

with regards

[alexg]

There is no such functionality. The user orders tables are not user-sortable. They are always sorted by descending date/time, as in most other exchanges.

It would be somewhat confusing for users to sort the open orders in any other way.

However, if you wish to do this anyway, it would be relatively straightforward with a jQuery plugin such as https://datatables.net/

You would have to bind the call to the plugin on the wallets_exchange_ready bubbling event, like so:

$( 'html' ).on( 'wallets_exchange_ready', function( event ) {
    $('.dashed-slug-wallets-exchange table').DataTable();
} );

Hope this helps.

[alexg]

That’s very strange.

I see your screenshot, but I am not able to reproduce this issue.

The matching algorithm will always match orders in this situation as far as I can tell.

I am thinking that maybe this is an object-cache issue? Could you try wiping your server’s cache(s) and then refresh your orderbook view?

Let me know please.

[alexg]

Hello,

Thanks. I am unable to reproduce the problem on 0.5.1-beta. The issue originally reported by bigblue has been fixed.

When a user refreshes the markets view, the currently selected market remains the same as before.

1. To be clear, what do you mean by “default page”? When you refresh the markets view, does the first market become selected?

2. Could you try clearing your browser’s cache and refreshing the page before you try again?

3. Do you see any JavaScript errors in your browser’s console?

[alexg]

Yes, this is a great idea, in fact I have been planning to do this but never got around to actually do it.

I will try to add it in one of the next releases.

with regards

[Author]

Posts