NEM Wallet Beta 2.4.4 - Bug bounty paid in XEM

and… one correction more. sorry

Einschränkungen bei der Verwendung von Namensräumen

Namensräume haben gewisse Einschränkungen in Bezug auf die Zeichen und Länge. Ein Root-Namensraum kann eine Länge von 16 Zeichen haben, während Sub-Namensraum eine Länge von 64 Zeichen haben können. Gültige Zeichen sind:

a, b, c, …, z, 0, 1, 2, …, 9, _ , -

Little correction:

I mean the first part…

Is the code on the official github repo?
So I can make a pull request. I would also like to update the Spanish version.

Since it is only updating my local repository, if you can issue a pull request, please do so there.

Ok great

1 Like

i still diden’t see the vote modul in my 1.4.0 wallet.
Any idea?

here a little graphical bug:

the distance to the right box is to short and the colons are covered.

hi,
Only the test net account can be displayed on the Vote module.

ah ok thx

1 Like

bug19-> Multisig accounts are blocked, you can’t do anything with them, if you try to send a transaction it won’t let you either. Multisig voting is done by a cosignatory account not the multisig account itself. When you log with an account that is cosignatory you will see the multisig tab on the right, and you can select from all the multisig accounts you can vote for. Although yes, the sent successfully message should not be there.

Ok, but msg about success shoudnt be displayed.

Btw, Can I expect for any bounties for my work?

Just want to say that I have the same message “You have already Voted on this Poll” for all the Polls (and I haven’t vote to a single one). I created a Testnet wallet for testing polls and I don’t currently have any test XEMs and I don’t have public key as no transaction has been made with that account. Maybe it explains the problem.

so, completed the german translation and added Spanish language as well:

1 Like

Hi, I just now cloned the github repo with the intention to contribute something in the future.

However when trying out running the tests (without changing anything to the code), I see that immediately 79 of them fail, and 7 remain pending.

after npm install and ‘gulp’, the application itself started successfully. Then I ran ‘npm test’ or ‘gulp test browserifyTests’ (should be same result, but this doesn’t seem to run the actual tests) and opened start.html within the test folder. That results in:

Is this the case for everyone or am I missing a step?
The README.md doesn’'t say anything on how to run these tests, would appreciate that.

Hi,

Yes a lot of tests are failling, I have not updated them in a while for 1.x.x.

Upcoming 2.0 has fixed test

Thanks for the quick reply. I’ll await the 2.0 version.

Just wondering, don’t you have any nightly test build of some sorts that fails on those tests?
Sorry to say but committing changes without updating the tests is very bad practice and I am a bit shocked that this application, that is dealing with peoples money after all, is so poorly maintained judging by a quick look at it.

You could also consider a githook that automatically runs the tests before a commit is approved.

I don’t have any nightly test build.

There is nothing that can go wrong with people money in my application.

Only bad thing that can happen is users losing the primary account private key, nothing else.

I know what I am doing and what everything does.

It is far from perfect but it is not poorly maintained

Well, if only in theory things could go wrong, right? Let’s say some developer accidentally mixed up the fields ‘Amount’ and ‘Fee’ in the send tab, and the amount filled in to send actually becomes the fee. In that case there is no error in the nem API whatsoever, just in the way the fields of the NanoWallet form are named and connected. Errors like that can still happen, even if someone by adding another language only translated the fields the other way around.

I’m sure you do, but since this is an open source project it is important that not just you but everyone can understand what it does by reading the code. And almost one third of the tests failing out-of-the-box doesn’t help that.

Developers must test on the Testnet before doing anything on Mainnet…

Regarding work added to the repo, I test and check developers work before merging and enable only testnet at first, like I did for the voting module recently.

I know, it is why I have made the nem-sdk https://github.com/QuantumMechanics/NEM-sdk and Nano 2.0

1 Like

That’s good to know. However, people just trying out the code like I just did are not aware yet of the formal test process, and seeing most unit tests fail right away gives a wrong impression. They’ll think: ‘oh no this application is a wallet for storing and paying with our XEM, but it has a lot of bugs in it’, or ‘developers don’t care at all for maintaining these tests in their code’.
Also, some developers might have malicious intentions (or be ‘trolls’) and might try to put dangerous code in there. Or they have good intentions but made a mistake that is hard to notice. It might slip past your code review or test one day, and then automated unit (or integration) tests will be an extra layer of security that could catch such issues.
So I do hope you guys keep up the good work and maintain your unit tests with every commit from 2.0 on.

Thanks for the SDK link as well.