mods for [email protected] #2
Conversation
| @@ -15,7 +15,7 @@ export class Auction4Reputation extends DaoSchemeDashboard { | |||
| protected wrapper: Auction4ReputationWrapper; | |||
| auctionsStartTime: Date; | |||
| auctionsEndTime: Date; | |||
| token: StandardTokenWrapper; | |||
| token: Erc20Wrapper; | |||
| auctionId: number = -1; | |||
There was a problem hiding this comment.
that is obsolete. I removed the line
| "lockingPeriodStartDate": "2019-02-18T00:00:00.000", | ||
| "lockingPeriodEndDate": "2019-03-21T00:00:00.000", | ||
| "governanceStartDate": "2019-04-04T00:00:00.000", | ||
| "lockingPeriodStartDate": "2019-02-18T12:00:00.000", |
There was a problem hiding this comment.
Does this times are for the dapp or landing page ?
If for dapp , why not read it from the contracts ?
There was a problem hiding this comment.
this is the default when not specified in the other setting sections below it.
The contract dashboards do not use these hard-coded settings at all (except for one special case in the externalLocking dashboard where it has to know the global starting date). The hard-coded settings are for everything except the contract dashboards.
There was a problem hiding this comment.
Undertaking the suggestion of pulling the start/end dates from one of the contracts, we would have to choose one contract from which to obtain the dates. There would be no gaurantee it will have the right dates nor be consistent with the other contracts.
The following is what in the UI would be affected:
- the locking period end date that is shown in text on the dashboard page
- when the "reputation you have earned" section becomes visible
- when the "Register" button becomes visible in the MGN dashboard
(Not much.)
A wrong date will be immediately and easily spotted, and I so far see no advantage in testing.
I am not convinced this is worth spending any more time on.
mods for [email protected]
The default Kovan and Rinkeby DAOs and their global period datetimes match the model spec.