Skip to content
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

Refactor permission tokens API #2052

Closed
Arjentix opened this issue Apr 4, 2022 · 1 comment
Closed

Refactor permission tokens API #2052

Arjentix opened this issue Apr 4, 2022 · 1 comment
Assignees
Labels
good first issue Good for newcomers iroha2-dev The re-implementation of a BFT hyperledger in RUST Refactor Improvement to overall code quality

Comments

@Arjentix
Copy link
Contributor

Arjentix commented Apr 4, 2022

Right now we have to identify PermissionTokens using some constant string. It makes sense for external API, but inside Iroha it could be strong typed.

If someone has something to add, feel free to leave a comment

@Arjentix Arjentix added iroha2-dev The re-implementation of a BFT hyperledger in RUST Refactor Improvement to overall code quality labels Apr 4, 2022
@appetrosyan appetrosyan added the good first issue Good for newcomers label Jun 2, 2022
@QuentinI
Copy link
Contributor

After some consideration and failed experiments I can't come up with a satisfactory design that would allow us to both create permission tokens dynamically and have them as completely independent types, as opposed to specialized wrappers around stringly-typed PermissionToken.

If we don't have/expect to have any cases where one would like to create and use new permission tokens via e.g. smartcontracts, we could make them strongly-typed and predefined per iroha build.

In the other case, I would propose bringing permission tokens more in line with other dynamically created entities: make them Identifiable and Registrable and require registering a token before granting it, like is the case with Roles. That would allow to easily query for all existing permission tokens and make them more consistent with everything else.

I'm more in favor of the second approach, but I think it depends mostly on whether we have any use-cases for defining new permission tokens at run-time, if there are none, it would make sense to go with the first one.

QuentinI pushed a commit to QuentinI/iroha that referenced this issue Jul 21, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Jul 21, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Jul 21, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Jul 25, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 3, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 3, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 3, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 8, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 10, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 11, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI pushed a commit to QuentinI/iroha that referenced this issue Aug 12, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
appetrosyan pushed a commit to QuentinI/iroha that referenced this issue Aug 12, 2022
Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
QuentinI added a commit that referenced this issue Aug 12, 2022
…2517)

* [refactor] #2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 6, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 6, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 6, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 7, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
BAStos525 pushed a commit to mversic/iroha that referenced this issue Sep 7, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
Signed-off-by: BAStos525 <jungle.vas@yandex.ru>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 8, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 9, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 9, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
BAStos525 pushed a commit to mversic/iroha that referenced this issue Sep 9, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
mversic pushed a commit to mversic/iroha that referenced this issue Sep 9, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
BAStos525 pushed a commit to mversic/iroha that referenced this issue Sep 9, 2022
… with definition (hyperledger-iroha#2517)

* [refactor] hyperledger-iroha#2052: implement PermissionTokenDefinition

Signed-off-by: Artemii Gerasimovich <gerasimovich@soramitsu.co.jp>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers iroha2-dev The re-implementation of a BFT hyperledger in RUST Refactor Improvement to overall code quality
Projects
None yet
Development

No branches or pull requests

4 participants