View Issue Details

IDProjectCategoryView StatusLast Update
0005338unrealircdpublic2019-11-27 12:18
ReporterGottemAssigned ToGottem 
Status resolvedResolutionfixed 
Product Version 
Target Version5.0.0-alpha1Fixed in Version5.0.0-rc2 
Summary0005338: 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> 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
TagsNo tags attached.
3rd party modules


child of 0005282 resolvedGottem Gottem's todo list yo 



2019-07-27 21:15

developer   ~0020794

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 =]


2019-07-29 18:07

administrator   ~0020796

Thanks, will check when I get back :)


2019-08-18 15:40

administrator   ~0020827

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.


2019-11-27 10:43

administrator   ~0021119

I should probably write a test for this... and then we'll see if there are any issues :)


2019-11-27 11:54

administrator   ~0021123

Last edited: 2019-11-27 11:55

View 3 revisions

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 :)


2019-11-27 12:18

administrator   ~0021124

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 :)

Issue History

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 View Revisions
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 View Revisions
2019-11-27 11:55 syzop Note Edited: 0021123 View Revisions
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