View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001252||Anope Development (1.9.x series)||HostServ||public||2011-03-13 19:14||2011-04-22 08:27|
|Summary||0001252: Main and grouped nicks in vHost activating, while enabling the directive "HSRequestMemoOper".|
|Description||MemoServ always sends memos from the main nick of the group. This fact takes part also in "HSRequestMemoOper" feature.|
Though, a vhost activating must be made on the specific grouped nick, which sent the request. Otherwise, no vHost will be found.
|Steps To Reproduce||- Enable "HSRequestMemoOper" directive in the conf [requires restart].|
- Create and enter some grouped nick, and request a vHost.
- Opers and host setters will see a new memo from the main nick:
(MemoServ) You have a new memo from Main_Nick.
(MemoServ) Type /msg MemoServ READ 1 to read it.
- Content of memo:
(MemoServ) Memo 1 from Main_Nick (Mar 13 18:39:52 2011 GMT). To delete, type: /msg MemoServ DEL 1
(MemoServ) [auto memo] vHost This.is.some.host has been requested.
- Send the command "/hs activate Main_Nick"
- You will get an error message:
(HostServ) No request for nick Main_Nick found.
- "/hs waiting" output:
(HostServ) 0000001 Nick:Gouped_Nick, vhost:This.is.some.host (Gouped_Nick - Mar 13 18:39:52 2011 GMT)
(HostServ) Displayed all records (Count: 1)
|Additional Information||I assume that MemoServ sends the memos from the main nick for convenience purposes.|
I am not sure what can be a solution.
Maybe not allowing each nick from the group to have is own vHost? This way, activating any of the grouped nicks will do the work, just like "/cs access" etc.
|Tags||No tags attached.|
||This should be fixed in the 1.9.5 branch in commit 7d2f634de2504864c08fff49a73575cf67c76e0d.|
||Committed to 1.8 GIT in 841b3f689eed.|
||hs_request uses the main memo_send function in memoserv.c, so to fix this we would need to modify that (which would affect all memos), or do some fun code duplication in hs_request.|
any particular reason this is a no-fix for 1.8?
There is no reason why the display nick couldn't optionally be displayed as the memo sender.. If I remember correctly all logic using the sender string assumes it s an alias and can even deal with that alias being missing (expiring nicks..?).
Alternatively, in the unlikely event there is something preventing that, at the very least the request string should be updated to include the origin of the request..
||Won't fix in 1.8, moving to 1.9.|
|2011-03-13 19:14||MeiR||New Issue|
|2011-03-14 20:00||Adam||Project||Anope Stable (1.8.x series) => Anope Development (1.9.x series)|
|2011-03-14 20:01||Adam||Note Added: 0005764|
|2011-03-14 20:01||Adam||Assigned To||=> Adam|
|2011-03-14 20:01||Adam||Status||new => acknowledged|
|2011-03-15 14:41||Viper||Note Added: 0005769|
|2011-03-15 14:41||Viper||Note Edited: 0005769||View Revisions|
|2011-03-15 23:59||Adam||Note Added: 0005772|
|2011-03-25 00:47||Viper||Note Added: 0005777|
|2011-04-22 08:27||Adam||Note Added: 0005798|
|2011-04-22 08:27||Adam||Status||acknowledged => resolved|
|2011-04-22 08:27||Adam||Resolution||open => fixed|