View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005338 | unreal | ircd | public | 2019-07-24 19:25 | 2019-11-27 12:18 |
| Reporter | Gottem | Assigned To | Gottem | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 5.0.0-alpha1 | Fixed in Version | 5.0.0-rc2 | ||
| Summary | 0005338: Port m_forward (partially) | ||||
| 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 | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
First version is done, I simply edited src/modules/chanmodes/link.c and added m_forward's +L chmode *and* its extban functionality. I didn't want to fuck with the path too much, but I think it makes more sense to have it in src/modules. Ain't gonna move that shit without feedback obviously. :D Couple o' things: * The extban was renamed from ~f: to ~L: to keep it consistent with the channel mode * Instead of bothering to check for blocked forwards, it will always attempt to forward because it will be restricted by bouncedtimes anyways: Message(470): [Link] Cannot join channel #foo (you are banned) -- transferring you to #loopback Message(470): [Link] Cannot join channel #loopback (channel is invite only) -- transferring you to #foo Message(470): [Link] Cannot join channel #foo (you are banned) -- transferring you to #loopback Message(470): [Link] Cannot join channel #loopback (channel is invite only) -- transferring you to #foo Message(470): [Link] Cannot join channel #foo (you are banned) -- transferring you to #loopback -hub.u5.home.lan- *** Couldn't join #loopback ! - Link setting was too bouncy Message(470): [Link] Cannot join channel #foo (you are banned) -- transferring you to #bar Message(470): [Link] Cannot join channel #bar (you are banned) -- transferring you to #joinable I realised that if you check for blockades and/or leave out intermediary channels, you may miss useful info to troubleshoot a possible loop :D * The extban doesn't actually return 1 from is_banned() because the forward itself has to be done from PRE_LOCAL_JOIN, where I have to extract the channel part anyways so it seemed redundant * The extban takes precedence over all (obviously), after that the order is (in case you hit multiple restrictions, although it doesn't really matter): +O, +z, +R and finally whatever can_join() condition fails first (ERR_BANNEDFROMCHAN, ERR_INVITEONLYCHAN, ERR_CHANNELISFULL, ERR_BADCHANNELKEY) * I took some inspiration from the account and msgbypass extbans with regards to stacking and shit, it seems good (+b ~L:#topkeks:~c:#banned properly forwards me to #topkeks if I'm a member of #banned) but should prolly get a confirmation about that :> * I removed the link_can_join_limitexceeded() function and respective hook because it was no longer necessary * Helpop docs need adjustment too but I'm not sure what you wanna do with the other languages :D * I didn't add the better_override stuff either because we haven't discussed that shit yet * The module's version was originally 4.2 but I made it 5.0 due to the huge jump in features, feel free to readjust though =] |
|
|
Thanks, will check when I get back :) |
|
|
Looks good I think. You mention some remaining issues, like helpop. Maybe go through the above list of things together and see what to do. Only thing I noticed is that a timed forward is settable but will not have an effect (+b ~t:10:~f:#channel:somenick!*@*). That's easy to fix though. And yeah, I wonder who would want this but hey.. why not :D. Just mentioning it here before I forget. |
|
|
I should probably write a test for this... and then we'll see if there are any issues :) |
|
|
Tests are now done for +b ~f, and for +L it tests the cases: +l +k +i +b. Not tested currently are registered / oper / secure. Fixed a numeric 470 issue, which was also present in UnrealIRCd 4 (so not caused by you). Looks good to me... only the ~t issue remains with ~f I think. I'll have a go at that and then this can be closed ? Oh right, docs too. EDIT: docs were already updated for +b ~f at least :) |
|
|
Fixed the +b ~t:100:~f:... not working. Also, last minute change, unrelated to this bug report: changed +L to require +o or higher, rather than requiring +q (channel owner). It was the only channel mode to require +q and for no good reason. Updated docs on +L and +f both helpop and online. And you are right, translations are not updated, that would be something for translators.. I should probably prod them now that U5 release is coming closer :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-07-24 19:25 | Gottem | New Issue | |
| 2019-07-24 19:25 | Gottem | Status | new => assigned |
| 2019-07-24 19:25 | Gottem | Assigned To | => Gottem |
| 2019-07-24 19:25 | Gottem | Issue generated from: 0005282 | |
| 2019-07-24 19:25 | Gottem | Relationship added | child of 0005282 |
| 2019-07-27 20:57 | Gottem | Description Updated | |
| 2019-07-27 21:15 | Gottem | Note Added: 0020794 | |
| 2019-07-27 21:15 | Gottem | Status | assigned => has patch |
| 2019-07-29 18:07 | syzop | Note Added: 0020796 | |
| 2019-08-18 15:17 | syzop | View Status | private => public |
| 2019-08-18 15:38 | syzop | Note View State: 0020794: public | |
| 2019-08-18 15:40 | syzop | Note Added: 0020827 | |
| 2019-11-27 10:43 | syzop | Note Added: 0021119 | |
| 2019-11-27 11:54 | syzop | Note Added: 0021123 | |
| 2019-11-27 11:54 | syzop | Note Edited: 0021123 | |
| 2019-11-27 11:55 | syzop | Note Edited: 0021123 | |
| 2019-11-27 12:18 | syzop | Status | has patch => resolved |
| 2019-11-27 12:18 | syzop | Resolution | open => fixed |
| 2019-11-27 12:18 | syzop | Fixed in Version | => 5.0.0-rc2 |
| 2019-11-27 12:18 | syzop | Note Added: 0021124 |
