Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ups]

Hi,
Some Suggestions about /ns suspend:

1) The nick of the oper that suspends a nick and the reason, should appear on the /ns info nick, (like with what happens with chanserv suspends);

2) When the nick is suspend should be added a sqline, with the reason of the given in suspend command (instead of the actual message:  Being held for registered user);

3) When a nick is suspended they nick should be automatically changed (like what happens with the /ns forbid).

Thanks for you attention.

[Jobe]

If this request is considered, the earliest it will be implimented is during the 1.9.* series.

THe alternative is for a module to do this if possible.

[Jan Milants]

i think you don't really understand the point of the suspend command... you compare it to forbid all the time, but there s a huge difference between them.
FORBID forbids a nickname from being used whereas SUSPEND suspends all access to anope. This doesn't influence the ability to use the nickname, it merely makes it impossible to gain access to anope.

i do agree on your first suggestion though.. the nick of the oper should be shown...

[katsklaw]

Hi,
Some Suggestions about /ns suspend:

1) The nick of the oper that suspends a nick and the reason, should appear on the /ns info nick, (like with what happens with chanserv suspends);

2) When the nick is suspend should be added a sqline, with the reason of the given in suspend command (instead of the actual message:  Being held for registered user);

3) When a nick is suspended they nick should be automatically changed (like what happens with the /ns forbid).

Thanks for you attention.

My personal opinion on this:

1> Users have no need or reason to know why other users accounts are suspended, nor do they need to know who did it. IMHO, Users don't need to see /kill reasons either, they just need to see the user quit by kill. Opers on the other hand might find the info useful so if this info was for opers only, I'd agree.
2> See Viper's note above.
3> agreed.

[Aragon]

Hi

In addition to the other suggestions I also think the ability to set an expiry time on the suspension would be useful.

As for suspend/forbid, I actually agree with the original poster.  The big difference between suspend and forbid is that forbid destroys all the nick data.  To undo a forbid the nick has to be dropped and reregistered, and so the user looses all his/her memos, history, settings, channel access, etc.  Suspend does not do this, but just because it doesn't destroy the nick doesn't mean I still want to allow use of a suspended nick.

I've been going through the current (1.8) nick database structure and noticed that the suspend reason overwrites the nick's last quit message.  Why is this?

Does anyone know if any of these changes has been considered for 1.9?

[Jan Milants]

The nick account is actually destroyed before it is forbidden, not during the drop to undo it..

The difference between forbid and suspend is that suspend is considered a temporary measure that can be undone whereas forbid is not. If a user is suspected of something his account can be suspended without affecting that users ability to keep using his nick. So suspend targets the services account, NOT the nickname.
Forbid on the other hand targets the nickname. It drops an account matching that nickname before putting the forbid in place simply because it would be useless to still have one in place.
If you want to prevent a nickname from being used I suggest you look into operserv SQLINE command.

As for the idea of having an expiry time, that would be interesting as suspend can be used as a punishment of some sorts, revoking services access for example for a certain period. On the other hand that s exactly what OS IGNORE does..

And about the last quit message: it overwrites the last quit message because at the time the user becomes suspended services will no longer recognize him. This is made apparent in ns info this way.

And at this time nothing of this has been considered for 1.9.
A timer sounds like a good idea, but the difference between forbid and suspend will be kept.

[Aragon]

If a user is suspected of something his account can be suspended without affecting that users ability to keep using his nick. So suspend targets the services account, NOT the nickname.

Hmm, well that is odd then because with my 1.8 setup services immediately changes a user's nick when he tries to set it to a nick that has been suspended... essentially doing the same as a Qline less efficiently.

[Aragon]

And about the last quit message: it overwrites the last quit message because at the time the user becomes suspended services will no longer recognize him. This is made apparent in ns info this way.

I was wondering more from the point of view of database design.  Storing the suspension reason there seems like a hack to me.  For one it overloads a field instead of creating a new one, and stores the information in the wrong place (nickalias rather than nickcore) so ends up being duplicated for every nickalias linked to the suspended nick.  /nickserv info on a suspended nick ends up being misleading too because the suspension reason is exposed in the last quit message of all the linked nicks.

A timer sounds like a good idea, but the difference between forbid and suspend will be kept.

Is the project open to accepting patches?