Open HashWarlock opened 2 years ago
This can also start the discussion on Logic
for properties.
Removing the Locked
error sounds like a good idea.
So it seems the Property should map to an object that is {isMutable: bool, value: something}
and just do a check on its existence or mutability?
I assume the issuer should be able to update the properties if the property is mutable but the issuer is not the owner, correct?
initial attempts to implement this failed, running into an issue refactoring because of query_properties
.
tried changing the .map
line to
.map(|(key, mutable, value)| PropertyInfoOf::<T> { key, mutable, value })
after changing PropertyInfo
to
pub struct PropertyInfo<BoundedValue> {
/// Key of the property
// #[cfg_attr(feature = "std", serde(with = "serialize::vec"))]
pub key: BoundedKey,
/// Value of the property
// #[cfg_attr(feature = "std", serde(with = "serialize::bool"))]
pub mutable: bool,
/// Value of the property
#[cfg_attr(feature = "std", serde(with = "serialize::vec"))]
pub value: BoundedValue,
}
but there's some type mismatch happening here that I can't figure out.
Currently only the
issuer
can set aProperty
& if a NFT islocked
then theProperty
cannot be changed or removed. Based on the spec setproperty.md, the user should be able to customize these properties if they are mutable. We have also run into this problem with flexibility for a project on Phala utilizing RMRK NFTs.If we take a look at the logic here, the only way to update a
Property
for a NFT is if the Collectionissuer
is thesender
AND theissuer
owns the NFT. https://github.com/rmrk-team/rmrk-substrate/blob/a3abdac27660099baeb50b3db91fadbf66b7e7ea/pallets/rmrk-core/src/functions.rs#L48-L69