Summary | realms get lost when storing rules |
Queue | Ingo |
Queue Version | HEAD |
Type | Bug |
State | Resolved |
Priority | 2. Medium |
Owners | |
Requester | adrieder (at) sbox (dot) tugraz (dot) at |
Created | 03/23/2006 (7108 days ago) |
Due | |
Updated | 03/27/2006 (7104 days ago) |
Assigned | 03/24/2006 (7107 days ago) |
Resolved | 03/27/2006 (7104 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
committed?
should address this. Have you tested it?
"true" and keeps the realm if hordeauth is set to "full". And it does
it correctly for the backend. But there are multidomain/server setups
where people have to use realms for horde applications, because there
could exist the same usernames on different server (e.g. imapservers
for imp). Therefore prefs and so on should be distinguishable. On the
other hand, the imap/sieve backend does not know anything about
realms. This seems to be the problem. In older versions of ingo this
situation was handled correctly.
State ⇒ Feedback
should address this. Have you tested it?
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ realms get lost when storing rules
Queue ⇒ Ingo
doesn't know anything about the realm), users get logged in to the
sieve server correctly but the ingo specific prefs get saved without
the full hordeauth (user@realm) in the prefs database (the same is for
the ingo sql storage). This means, that the sieve scripts get
transferred correctly to the sieve backend but will newer again show
up on the UI.
A workarround for this is to use Auth::getAuth() instead of
Ingo::getUser() in horde/ingo/lib/Storage/prefs.php and/or
horde/ingo/lib/Storage/prefs.php