🐛 Depositing PalletAttributeSet on incorrect nft (#2740)

## Context

Implementing `HolderOf(collection_id)` we have observed a fancy glitch
where pallet deposits event with incorrect values

### Test case 

[Observe following
extrinsic](https://assethub-polkadot.subscan.io/extrinsic/0xdc72321b7674aa209c2f194ed49bd6bd12708af103f98b5b9196e0132dcba777)

To mint in collection `51` user needs to be `HolderOf(50)`.
Therefore current user is owner of item `394` `witness_data {
owned_item: 394 }`

All checking is done correctly, storage is updated correctly

 
![photo_2023-12-18 16 07
11](https://github.com/paritytech/polkadot-sdk/assets/22471030/ca991272-156d-4db1-97b2-1a2873fc5d3f)

However the event which is emitted does not make semantic sense as we
updated storage for `50-394` not for `51-114`

![photo_2023-12-18 16 07
17](https://github.com/paritytech/polkadot-sdk/assets/22471030/c998a92c-e306-4433-aad8-103078140e23)

## The fix 

This PR fixes that depositing `PalletAttributeSet` emits correct values.

---------

Co-authored-by: Jegor Sidorenko <jegor@parity.io>
Co-authored-by: Jegor Sidorenko <5252494+jsidorenko@users.noreply.github.com>
This commit is contained in:
Viki Val
2024-03-09 07:32:53 -08:00
committed by GitHub
parent 9f5d9fa96f
commit 1c435e91c1
2 changed files with 8 additions and 2 deletions
+6
View File
@@ -440,6 +440,12 @@ fn mint_should_work() {
account(2),
Some(MintWitness { owned_item: Some(43), ..Default::default() })
));
assert!(events().contains(&Event::<Test>::PalletAttributeSet {
collection: 0,
item: Some(43),
attribute: PalletAttributes::<<Test as Config>::CollectionId>::UsedToClaim(1),
value: Nfts::construct_attribute_value(vec![]).unwrap(),
}));
// can't mint twice
assert_noop!(