setParent() function does not lock permissions

[MilSci]

Please describe the problem you are having in as much detail as possible:
When running a setParent() function with lockPermissions() being true, it fails to actually sync the permissions with the parent's permissions

Include a reproducible code sample here, if possible:

chan.setParent(config.server, { lockPermissions: true})
//chan is a fetched channel
//config.server is the ID to the category

Further details:

• discord.js version: v12
• Node.js version: v12
• Operating system: Windows x86-64
• Priority this issue should have – please be realistic and elaborate if possible:
  Can be a larger issue since most people might use this feature to create new channels

• I have also tested the issue on latest master, commit hash:

[redbrain]

I'm having this issue as well.

[almostSouji]

The proper fix to this issue will take some time, as it requires us to restructure how #setParent works internally, i will do so in the linked issue above.

For now you can use a work-around approach of setting the overwrite to the overwrites of the to-be parent channel alongside the parent during an #edit instead of #setParent call as shown below:

const parent = guild.channels.resolve(<parent_id>)
const data = {
	parentID: parent.id,
	permissionOverwrites: parent.permissionOverwrites
}
channel.edit(data)

The current #setParent call works similar to that

discord.js/src/structures/GuildChannel.js

Lines 388 to 397 in d827544

	setParent(channel, { lockPermissions = true, reason } = {}) {
	return this.edit(
	{
	// eslint-disable-next-line no-prototype-builtins
	parentID: channel !== null ? (channel.hasOwnProperty('id') ? channel.id : channel) : null,
	lockPermissions,
	},
	reason,
	);
	}

for now #setParent internally calls #edit and passes a setting that's not available to the API call

⚠ This is not how moving channels between categories is supposed to work, this is a work-around and should be replaced once the linked PR reaches stable.

📝 Please leave this issue open, as again, this is a work-around and it should be closed with the proper implementation of category moving.