View Issue Details

IDProjectCategoryView StatusLast Update
0005338unrealircdpublic2019-08-18 15:40
ReporterGottemAssigned ToGottem 
PrioritynormalSeverityfeatureReproducibilityN/A
Status has patchResolutionopen 
Product Version 
Target Version5.0.0-alpha1Fixed in Version 
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> 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
TagsNo tags attached.
3rd party modules

Relationships

child of 0005282 assignedGottem Gottem's todo list yo 

Activities

Gottem

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

syzop

2019-07-29 18:07

administrator   ~0020796

Thanks, will check when I get back :)

syzop

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.

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