caller or token owner should be able to approve self as operator for …

[jrkosinski]

…own tokens.

Motivation:
As discussed, the EIP doesn't explicitly state that someone can't be their own operator for their own tokens. It has no effect per se, other than clearing any existing operator for the same tokens. An address being its own approver does no harm, and does not seem to be explicitly forbidden by the EIP.

approve(my_address, my_token_id) -> results in getApproved(my_token_id) returning the address of the owner. Now the token owner has all the same rights that they already had anyway.

Same for setApprovalForAll(my_address) -> the token owner is now the operator for all of its own tokens.

Changes

• removed check for (operator == sender) in setApprovalForAll.
• removed error ApproveToCaller (no longer being used)
• modified unit test that was testing for that error, to check instead that the call is not reverted.
• and then modified that same test to check that isApprovedForAll returns true for the token owner
• added a new test in "setApprovalForAll" to check that similarly, an address can call approve to set itself as operator for its own tokens
• added a further test that, once an address has called approve to set itself as operator, transferring will clear the approval (as it would for any other operator)

[Vectorized]

:)

[Vectorized]

@jrkosinski Psst, can you help fix the linter issues for the test file?

[jrkosinski]

Hi Vectorized, Yeah, I saw that; I will fix those issues tonight (in a few hours in my timezone) Thanks, John

…

On Fri, Aug 12, 2022 at 3:16 PM Vectorized ***@***.***> wrote: @jrkosinski <https://github.com/jrkosinski> Psst, can you help fix the linter issues for the test file? — Reply to this email directly, view it on GitHub <#407 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATG4NR5VKPKBW5PZFOFWXTVYYB4BANCNFSM56I2SS6Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Vectorized]

@cygaar LGTM, what do you think?