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
(Fix) Investors incorrect max cap #1072
Conversation
- Prevents adding more addresses if the sum of the maxCaps exceeds the tiers' supply
- triggers an error for maxCap if it exceeds the remaining tier's supply - prevent displaying error messages if field wasn't modified yet - update maxCap validation if supply has been modified
- Validate supply against sum of whitelist's maxCap - Make validation active only when whitelist is enabled - Fix warning message when trying to read an array index out of bound
- used bigNumber's eq() when === cannot be used - removed unused variables - replaced == with === - disabled linting warnings - stepTwo/index.js:17 - DeploymentStore.js:80 - blockchainHelpers.js:380
@fernandomg
Expected result:
Actual result:
|
@dennis00010011b that was quick! thanks for the catch, will review it |
Black Duck Security ReportMerging #1072 into 2.0 will not change security risk. Removed ComponentsClean: 2 |
Ok, so after reviewing the different scenarios that will arise with this PR and have a chat with @vbaranov. It was decided to close this PR and create a new solution for #1067, which is #1067 (comment) |
Closes #1067
This PR fixes all the related issues with whitelisted addresses and tier's supply. Scenarios that I took into account for both strategies (MintedCapped and DutchAuction):
maxCap
of[100, 200, 300]
ifsupply
is400
, then only the first two addresses will be added.supply
value will be validated against the sum of themaxCap
s. It should not be less than themaxCap
sum.manage
screensupply
cannot be edited, so whitelist addresses will be checked.Note
The scenario that I didn't fix, due to the complexity of the fix itself (it would require several modifications and would be better to address it in a separate PR), has to be with
manage
screen and an address values modification.As you can see in the screenshot
Despite having
1011
tokens available, and requiring only28
extra tokens to change1972
to2000
, it's giving the error as it considers that the address is new and not a modification of an existing one.Also: