[Community Permissions]: Disable amount input for specific collectibles

[micieslak]

Bug Report

Description

When specific token from a collection is selected, it shouldn't be possible to specify amount different than 1.

Steps to reproduce

1. Go to community settings (for a community you own)
2. Permissions section, "Add new permission" button
3. Who holds section - collectibles, select collectible collection like "CryptoKitties" on the screenshot below
   
4. Select collectible from the collection

Expected behavior

The collectible should be
a) added to the selector immediately (amount 1) or
b) the panel with collectible name, amount and "add" button should be presented but with amount input disabled and amount set to "1"

@benjthayer @xAlisher please decide which option is better her.

Actual behavior

User can freely specify amount

Additional Information

[benjthayer]

Hey @noeliaSD @micieslak
Route a) added to the selector immediately should be done in this case (where the collectible is a one of a kind) :)
I've added a couple of flow arrows into the designs to clarify:
https://www.figma.com/file/17fc13UBFvInrLgNUKJJg5/Kuba%E2%8E%9CDesktop?type=design&node-id=22772-496502&t=bO2xh3Cg3mbrnUey-4

Thanks for checking!

[noeliaSD]

Added summary here:

1. If collectible is unique (item inside a collection), number 1 will not be displayed, since it only exists 1 element of this type. In this situation, the item will be automatically added into the list and amount dropdown view will not be displayed.
   
   Also, when the item is clicked the following view will be displayed only with the Remove button:

2. For the rest of cases (selecting any in a collection type or, our minted collectibles), number 1 should be displayed.
   

[alexjba]

Route a) added to the selector immediately should be done in this case (where the collectible is a one of a kind) :)

@benjthayer Community minted tokens with 1 total supply is also considered unique and should follow this flow?

[benjthayer]

Route a) added to the selector immediately should be done in this case (where the collectible is a one of a kind) :)

@benjthayer Community minted tokens with 1 total supply is also considered unique and should follow this flow?

Hey Alex, I discussed this with Alisher. In the instance where the token being used for the permission has a total supply of 1 (and therefore is similar to a 1:1 collectible), we could clarify that the permission can only be created with 1 as the amount by including Max. 1 in with the asset. It should logically follow for the user then that when they click the token that they skip the definition of the amount step and the token is added directly into the permission in the same way we do for the 1:1 collectible.

Interested to get thoughts on whether this feels intuitive!

cc @John-44 @xAlisher

[alexjba]

Route a) added to the selector immediately should be done in this case (where the collectible is a one of a kind) :)

@benjthayer Community minted tokens with 1 total supply is also considered unique and should follow this flow?

Hey Alex, I discussed this with Alisher. In the instance where the token being used for the permission has a total supply of 1 (and therefore is similar to a 1:1 collectible), we could clarify that the permission can only be created with 1 as the amount by including Max. 1 in with the asset. It should logically follow for the user then that when they click the token that they skip the definition of the amount step and the token is added directly into the permission in the same way we do for the 1:1 collectible.

Interested to get thoughts on whether this feels intuitive!

cc @John-44 @xAlisher

@benjthayer Sounds good to me. One thing I've noticed while checking the designs is that we have a different indication of 1:1 assets in the Permissions view vs Airdrop view. I guess we should align this, right?

[benjthayer]

@benjthayer Sounds good to me. One thing I've noticed while checking the designs is that we have a different indication of 1:1 assets in the Permissions view vs Airdrop view. I guess we should align this, right?

Ah, the one in permissions is an exploration Alisher did as we were discussing this - so I will remove it.

The reason we ultimately landed on Max. 1 instead of Max. supply 1 is that it is more general - it can cover both:

1. Maximum supply (i.e. the smart contract relating to the token being selected was minted with a total finite supply of 1)

• This is useful for permissions - Max. 1 in this instance tells the users that a permission using this token can only have an amount of 1 given this was the total finite supply. No more than 1 of these tokens ever existed.

2. Assets remaining in a smart contract

• This is useful for airdropping - Max. 1 in this instance tells the user that there is a maximum of 1 remaining token in the smart contract (the total finite supply may have been more than 1 but there is now only 1 remaining as the others have been airdropped already). That's why using the word supply here is a little off the mark as we use the term available not remaining supply to indicate how many remaining tokens there are in the smart contract.

Hope that rationale makes sense! :)

[alexjba]

@benjthayer Sounds good to me. One thing I've noticed while checking the designs is that we have a different indication of 1:1 assets in the Permissions view vs Airdrop view. I guess we should align this, right?

Ah, the one in permissions is an exploration Alisher did as we were discussing this - so I will remove it.

The reason we ultimately landed on Max. 1 instead of Max. supply 1 is that it is more general - it can cover both:

1. Maximum supply (i.e. the smart contract relating to the token being selected was minted with a total finite supply of 1)

• This is useful for permissions - Max. 1 in this instance tells the users that a permission using this token can only have an amount of 1 given this was the total finite supply. No more than 1 of these tokens ever existed.

2. Assets remaining in a smart contract

• This is useful for airdropping - Max. 1 in this instance tells the user that there is a maximum of 1 remaining token in the smart contract (the total finite supply may have been more than 1 but there is now only 1 remaining as the others have been airdropped already). That's why using the word supply here is a little off the mark as we use the term available not remaining supply to indicate how many remaining tokens there are in the smart contract.

Hope that rationale makes sense! :)

Thanks for explaining! Didn't knew there's a different meaning in the amounts shown in Airdrop vs. Permissions view.
We use the same UI component for both views and from what I understand so far we should make it configurable to support these 2 states:

1. Show the available supply. Supports infinite, number and Max. 1 for 1:1 tokens - used in Airdrop view
2. Show the total supply only when the amount is 1 (Max. 1) - used in Permissions view

Please correct me if I'm wrong.

[noeliaSD]

@benjthayer Sounds good to me. One thing I've noticed while checking the designs is that we have a different indication of 1:1 assets in the Permissions view vs Airdrop view. I guess we should align this, right?

Ah, the one in permissions is an exploration Alisher did as we were discussing this - so I will remove it.
The reason we ultimately landed on Max. 1 instead of Max. supply 1 is that it is more general - it can cover both:

1. Maximum supply (i.e. the smart contract relating to the token being selected was minted with a total finite supply of 1)

• This is useful for permissions - Max. 1 in this instance tells the users that a permission using this token can only have an amount of 1 given this was the total finite supply. No more than 1 of these tokens ever existed.

2. Assets remaining in a smart contract

• This is useful for airdropping - Max. 1 in this instance tells the user that there is a maximum of 1 remaining token in the smart contract (the total finite supply may have been more than 1 but there is now only 1 remaining as the others have been airdropped already). That's why using the word supply here is a little off the mark as we use the term available not remaining supply to indicate how many remaining tokens there are in the smart contract.

Hope that rationale makes sense! :)

Thanks for explaining! Didn't knew there's a different meaning in the amounts shown in Airdrop vs. Permissions view. We use the same UI component for both views and from what I understand so far we should make it configurable to support these 2 states:

1. Show the available supply. Supports infinite, number and Max. 1 for 1:1 tokens - used in Airdrop view
2. Show the total supply only when the amount is 1 (Max. 1) - used in Permissions view

Please correct me if I'm wrong.

Yes!
And in both cases the dropdown will skip the amount input view, so the item will be directly added.

[alexjba]

The amount input should not be disabled for assets even when the supply is 1 because the user can own fractions of the asset.

[alexjba]

Depends on #11437

Moving this to C3 as it's not sure there's enough time to implement the backend support.