Add lock/unlock method to Thread class

[BaeFell]

Adds ability to lock/unlock threads using the Thread class.

[BaeFell]

Not entirely sure how I ended up running composer run-script cs and it had quite a few changes to make.

[valzargaming]

Other maintainers have argued that functions like this, which aren't directly documented by Discord, make the overall library harder to maintain. My primary question when reviewing this PR (and the Thread class in general) is: why doesn't the Channel class have a similar rename method using the patch endpoint, as the Thread class does? While I don't share the opinion that such functions complicate maintenance, it does suggest that these features might be better implemented as a shared trait among similar classes. I believe this PR is appropriate because it addresses a thread-specific issue (locking and unlocking) that doesn't apply to other contexts, so unless someone objects I am 100% for merging this.

[BaeFell]

I'm with you having functions like this or common ones shared as a class trait is a good thing. As long as it's possible to do something and it's not completely unintended like modals having dropdowns, then having that functionality helps everyone.

[BaeFell]

I messed up my PR/commit 🤦 My changes to the CommandBuilder were meant to go separate. I'm awful with Git, any advice would be appreciated to solve this 🙏

[Log1x]

I messed up my PR/commit 🤦 My changes to the CommandBuilder were meant to go separate. I'm awful with Git, any advice would be appreciated to solve this 🙏

Undo your command builder changes here and re-push. Afterwards, checkout back to the main branch of your fork using git checkout master and then create a new branch for your command builder changes with git checkout -b fix/commandbuilder-context-description and re-commit your command builder changes.

[BaeFell]

I messed up my PR/commit 🤦 My changes to the CommandBuilder were meant to go separate. I'm awful with Git, any advice would be appreciated to solve this 🙏

Undo your command builder changes here and re-push. Afterwards, checkout back to the main branch of your fork using git checkout master and then create a new branch for your command builder changes with git checkout -b fix/commandbuilder-context-description and re-commit your command builder changes.

I'll give that a go tomorrow. Thank you!

[Log1x]

I'll give that a go tomorrow. Thank you!

I didn't realize you did this PR off of master – what I would do is close this PR and re-fork the repo ensuring you checkout a branch before doing your changes such as git checkout -b enhance/lock-unlock-thread – it'd also allow you to do your changes without running linting since as you noted it had quite a few unrelated changes.

[SQKo]

You should just create a new branch in your repository then cherry pick the latest commit. And then create new PR

Other maintainers have argued that functions like this, which aren't directly documented by Discord, make the overall library harder to maintain. My primary question when reviewing this PR (and the Thread class in general) is: why doesn't the Channel class have a similar rename method using the patch endpoint, as the Thread class does? While I don't share the opinion that such functions complicate maintenance, it does suggest that these features might be better implemented as a shared trait among similar classes. I believe this PR is appropriate because it addresses a thread-specific issue (locking and unlocking) that doesn't apply to other contexts, so unless someone objects I am 100% for merging this.

For case in Thread, there exists method archive() and unarchive() method, due to the fact that it can be done outside the conditions for threads->save() i,e. different permission/being owner of the thread or is using different endpoint/method.

Locked and unlocked did not have its own method because at that time you can just do $thread->lock = true then threads->save($thread)