cambiatus / contracts Goto Github PK

It should use the same structure for roles that we currently have, but on cambiatus.tk contract

Describe the bug
Right now we require a minimum of 2 votes to create a new action. The problem is that this causes a scenario where claims that require two votes (actually all scenario with an even number of required votes) we may reach a scenario of having half of the required votes as "approved" and "disapproved". This will create limbo scenario of ever pending claims.

To Reproduce
Steps to reproduce the behavior:

1. Create action with a number of two verifications (may have several more validators on the list)
2. Open a new claim
3. As the validators, vote positive as the first validator and negative as the second validator
4. See the zombie claim (never approved or disapproved)

Expected behavior
We should be able to make sure the claim reaches the end of its cycle. To make sure it will happen we should make sure we only accept odd numbers (but bigger than 1)

While trying to update different actions, we allow our users to set a validator list -- a - separated string with accounts.

Every time we are updating that list we first clear all elements from that action and recreate it with all the accounts sent on the validator_str param.

A weird thing happens when we try to send an update sometimes, the contract deletes action validators from another action.

Maybe this can be fixed by adding a scope, but it should work with indexes (current implementation has an action_index). Needs more simulation and investigation

Used to fill in what features are enabled on a community

Add and migrate a new community settings table, allowing for those toggles. Make sure the other actions don't work if set

While trying to approve/disapprove actions the contract throws "Can't vote on already verified claim" error from the server. Only the first verifier can verify Claims, all others will get an error.

You can reproduce it in the "AMTB" community with the passphrase razor cable someone foster material say this decade rocket agree move segment on http://staging.cambiatus.io/dashboard

Describe the bug
During the tests of cambiatus/frontend#485, @heltonlr found a bug where an action that was completed was not being correctly updated by event-source. We need to investigate further.

To Reproduce
We still don't have enough info to debug this

Expected behavior
As the action usages are completed, we need to make sure the action is correctly completed as well.

Screenshots
N/A

Cambiatus Env you are using
Staging

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Make sure expiration works for ticolones

Sentry Issue: FRONTEND-3RR

[EOS] assertion failure with message: Can't find any sale with given sale_id

we should update it to use require_auth2() to use a new permission (we need to decide its name). This will avoid a malicious attack to change the contract's code

Following up cambiatus/frontend#450, we need to limit the max number of the units to be 9999

https://github.com/cambiatus/contracts/blob/master/bespiral.community/bespiral.community.hpp
https://github.com/cambiatus/contracts/blob/master/bespiral.token/bespiral.token.hpp

Need to add a rule during action creation that the list must always have at least two verifiers

Roles will allow us to further improve how we handle granular governance in Cambiatus, its the first step towards a more decentralized community

as part of our security routine, change up all the contracts keys

Is your feature request related to a problem? Please describe.
We had a few minor bugs after feature deployment that could be avoided

Describe the solution you'd like
We we had a test stack on the smart contract that would be helpful. We can make sure the contract behaves the way we intent it to!

Describe alternatives you've considered
Using the default eosio std lib test framework. Some people has been using other test issues such as RSpec for this but I think integration tests aren't what we need for now. Unit tests will allow us to test the contract and other test suits will allow us to test the deployment flow

Additional context
here is how block one does the contract testing for reference: https://github.com/EOSIO/eosio.contracts/tree/master/tests

Sometimes while validating a claim we get this error message, this is a performance problem under our contract that we should fix

Sentry Issue: FRONTEND-2KB

deadline exceeded 32720us