View Revisions: Issue #5338

Summary 0005338: Port m_forward (partially)
Revision 2019-07-27 20:57 by Gottem
Description <~Syzop> regarding m_forward: I would like to see +L change to basically what you made +F there. I think it's in some bugid#
<~Syzop> after all, +L is quite useless atm ;p


<~Syzop> I think your ~f:#channel:<ban> is much better in that respect
<~Syzop> https://www.unrealircd.org/docs/Extended_Bans
<~Syzop> that makes the ~f:#channel thing a catagory 2 extban
<~Syzop> and then just allow all selectors from catagory 3
<~Syzop> and of course, if ~f rejects the join in case of multiple forwards, then it's fine (for now)


<~Syzop> and as for +B / +Q etc.. I would suggest to just hold off that for a moment.


One thing many people seem to forget/overlook is that m_forward also implements a "better override" thing. What this does is basically remove the need for opers to manually force themselves into restricted channels. Like if a channel is +i and the oper in question has an override privilege for it, he would normally have to do /sajoin or /invite himself to get in. With the better_override flag it will allow the /join itself (while also emitting a snomessage of course). The same is true for +R and +b.


There's also a public bug about this forwarding stuff (5267), but it's not really relevant to the current implementation plan anymore. :D
Revision 2019-07-24 19:25 by Gottem
Description <~Syzop> regarding m_forward: I would like to see +L change to basically what you made +F there. I think it's in some bugid#
<~Syzop> after all, +L is quite useless atm ;p


<~Syzop> I think your ~f:#channel:<ban> is much better in that respect
<~Syzop> https://www.unrealircd.org/docs/Extended_Bans
<~Syzop> that makes the ~f:#channel thing a catagory 2 extban
<~Syzop> and then just allow all selectors from catagory 3
<~Syzop> and of course, if ~f rejects the join in case of multiple forwards, then it's fine (for now)


<~Syzop> and as for +B / +Q etc.. I would suggest to just hold off that for a moment.

There's also a public bug about this (5267), but it's not really relevant to the current implementation plan anymore. :D