You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The NFT that represents the project in its given state should only exist once for the current version, or in 1155, there should only be one collection of that version. Currently, the user can mint an NFT from project C as it exists, say with two stems A and B. Another user can mint an NFT of project C with stems A and B as well. This ends up having two identical NFTs, just owned by different users. This should be prevented.
User Story
As a user, I should be able to mint a song into a token if there isn’t a token that exists with that exact combination of stems and collaborators. If a project has 3 stems on it and hasn’t been minted yet in that version, as a user, I should be able to mint that project. If a user comes along after me minting that project, and the project state hasn’t changed at all in the manner of new stems being added onto the project, then that second user should not be able to mint the project. In other words, there should only exist a version of an Arbor project at each state that the project has and no more than one per state.
“State” in this context means:
The project with 2 stems from 1 collaborator
The project with 3 stems from 2 collaborators
The project with 4 stems from 2 collaborators
The project with 5 stems from 3 collaborators
etc.
A project could only have an NFT representing one of these states, nothing more, and no tokens with the same “configuration”, or “state”.
Expected Behavior
Please provide a clear and concise description of what you expected to happen.
Steps to Reproduce
Steps to reproduce the behavior:
Go to '...'
Click on '....'
Scroll down to '....'
See error
References
Please add any references, screenshots, or links to anything that will be helpful to triage this bug.
OS & Device Information
Desktop (please complete the following information):
OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]
Smartphone (please complete the following information):
Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
Bug Notes
The NFT that represents the project in its given state should only exist once for the current version, or in 1155, there should only be one collection of that version. Currently, the user can mint an NFT from project C as it exists, say with two stems A and B. Another user can mint an NFT of project C with stems A and B as well. This ends up having two identical NFTs, just owned by different users. This should be prevented.
User Story
As a user, I should be able to mint a song into a token if there isn’t a token that exists with that exact combination of stems and collaborators. If a project has 3 stems on it and hasn’t been minted yet in that version, as a user, I should be able to mint that project. If a user comes along after me minting that project, and the project state hasn’t changed at all in the manner of new stems being added onto the project, then that second user should not be able to mint the project. In other words, there should only exist a version of an Arbor project at each state that the project has and no more than one per state.
“State” in this context means:
A project could only have an NFT representing one of these states, nothing more, and no tokens with the same “configuration”, or “state”.
Expected Behavior
Please provide a clear and concise description of what you expected to happen.
Steps to Reproduce
Steps to reproduce the behavior:
References
Please add any references, screenshots, or links to anything that will be helpful to triage this bug.
OS & Device Information
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: