fix(#231): next_cert_issuable_on is not used

Closes #231 (closed)

cert_meta.next_issuable_on is computed on genesis without this variable

requested review from @HugoTrentesaux

assigned to @c-geek

added C-runtime RN-runtime labels

added 2 commits

• 1e73e7b8 - 1 commit from branch 279-check-if-ud-is-using-well-pallet-balances
• d1720a05 - fix(#231 (closed)): next_cert_issuable_on is not used

Compare with previous version

changed milestone to %runtime-1000

changed the description

mentioned in merge request !307 (merged)

Some context for people who will read this later

There are two variables:

• next_creatable_identity_on in identity pallet which controls the identity creation period
• next_issuable_on in certification pallet which controls the certification period

For the moment, there is no additional constraint in identity creation and it is always equal to next cert. This was introduced by elois who thought we could limit further the identity creation which is a more sensitive operation than a certification.

On genesis

The idea of setting next_issuable_on in genesis based on next_cert_issuable_on was to prevent an identity to certify both just before migration and just after migration, which would be below the 5 days period.

With this MR, it seems to me that this feature disappears. Is this what you want? I'm ok with that but not sure to understand if this is actually about that.

cert_meta.next_issuable_on is computed on genesis without this variable

Are you thinking about apply_cert_period_at_genesis be true (default is false)? In this case, somebody who did not certify 5 days before migration will have to wait 5 additional days after migration.

With this MR, it seems to me that this feature disappears. Is this what you want? I'm ok with that but not sure to understand if this is actually about that.

No it is just about the fact that the variable next_cert_issuable_on was dead.

Are you thinking about apply_cert_period_at_genesis be true (default is false)? In this case, somebody who did not certify 5 days before migration will have to wait 5 additional days after migration.

Well yes, I did not see this condition. We could put it either to false or true, it won't make a big difference.

merged

mentioned in commit 666a862f

resolved all threads

mentioned in commit 2ab1e958