Getting 'The user name or password is incorrect.' error message. Note that the domain dropdown is disabled only some of the times.
(In reply to Gilad Chaplik from comment #0) > Getting 'The user name or password is incorrect.' error message. > > Note that the domain dropdown is disabled only some of the times. raised severity/priority to high. - it is consistent? - the 'The user name or password is incorrect.' message arrives from the engine - changing Whiteboard to 'infra' (maybe related to something with the new AAA stuff, not sure)
(In reply to Einav Cohen from comment #1) > (In reply to Gilad Chaplik from comment #0) > > Getting 'The user name or password is incorrect.' error message. > > > > Note that the domain dropdown is disabled only some of the times. > > raised severity/priority to high. > > - it is consistent? yes. cannot login. > > - the 'The user name or password is incorrect.' message arrives from the > engine - changing Whiteboard to 'infra' (maybe related to something with > the new AAA stuff, not sure) I actually not sure, we split the str in the client side, and > Note that the domain dropdown is disabled only some of the times. is ux
(In reply to Gilad Chaplik from comment #2) > (In reply to Einav Cohen from comment #1) > > (In reply to Gilad Chaplik from comment #0) > > > Getting 'The user name or password is incorrect.' error message. > > > > > > Note that the domain dropdown is disabled only some of the times. > > > > raised severity/priority to high. > > > > - it is consistent? > > yes. cannot login. > > > > > - the 'The user name or password is incorrect.' message arrives from the > > engine - changing Whiteboard to 'infra' (maybe related to something with > > the new AAA stuff, not sure) > > I actually not sure, we split the str in the client side, and did you try to debug the engine to see what are the parameters that are sent from the client? that way we will know for sure. > > > Note that the domain dropdown is disabled only some of the times. > > is ux
Did it reproduce in latest 3.5 build? master? It works well for me.
(In reply to Oved Ourfali from comment #4) > Did it reproduce in latest 3.5 build? master? > It works well for me. doesn't work in 3.5 build, yet. reproduces master. debugged it a bit, and when I pass to ExtensionProxy in LoginBaseCommand user='admin', it works, and when I pass user='admin@internal' it doesn't. maybe we need to split it somewhere a long the way.
Yair - please address that as soon as possible
we do not know if the suffix is profile name or part of principal, this is why there are two fields. for example, specify upn alonbl at profile redhat should be supported, if we accept @xxx within user name, then: alonbl@redhat should be supported, but how can we know if suffix is profile or not? for ui we added some magic of backward compatibility to accept these weird notations, but the ui has explicit two fields. when do you need to split at ui? the login always had two fields.
(In reply to Alon Bar-Lev from comment #7) > we do not know if the suffix is profile name or part of principal, this is > why there are two fields. > > for example, specify upn alonbl at profile redhat should be > supported, if we accept @xxx within user name, then: > alonbl@redhat should be supported, but how can we know if suffix > is profile or not? > > for ui we added some magic of backward compatibility to accept these weird > notations, but the ui has explicit two fields. > you mean "for api", right? > when do you need to split at ui? the login always had two fields. in the past we supported putting user@domain in the UI as well. But, I according to your answer, we can no longer support that, right? Makes sense to me, just wanted to make sure.
(In reply to Oved Ourfali from comment #8) > (In reply to Alon Bar-Lev from comment #7) > > we do not know if the suffix is profile name or part of principal, this is > > why there are two fields. > > > > for example, specify upn alonbl at profile redhat should be > > supported, if we accept @xxx within user name, then: > > alonbl@redhat should be supported, but how can we know if suffix > > is profile or not? > > > > for ui we added some magic of backward compatibility to accept these weird > > notations, but the ui has explicit two fields. > > > > you mean "for api", right? right, sorry. > > > when do you need to split at ui? the login always had two fields. > > in the past we supported putting user@domain in the UI as well. > But, I according to your answer, we can no longer support that, right? > > Makes sense to me, just wanted to make sure. we can do heuristics if it is important, but I think the support can be considered a bug :) the native backend interface should always accept two fields: user name and profile name in which user resides.
(In reply to Alon Bar-Lev from comment #9) > (In reply to Oved Ourfali from comment #8) > > (In reply to Alon Bar-Lev from comment #7) > > > we do not know if the suffix is profile name or part of principal, this is > > > why there are two fields. > > > > > > for example, specify upn alonbl at profile redhat should be > > > supported, if we accept @xxx within user name, then: > > > alonbl@redhat should be supported, but how can we know if suffix > > > is profile or not? > > > > > > for ui we added some magic of backward compatibility to accept these weird > > > notations, but the ui has explicit two fields. > > > > > > > you mean "for api", right? > > right, sorry. > > > > > > when do you need to split at ui? the login always had two fields. > > > > in the past we supported putting user@domain in the UI as well. > > But, I according to your answer, we can no longer support that, right? > > > > Makes sense to me, just wanted to make sure. > > we can do heuristics if it is important, but I think the support can be > considered a bug :) > I tend to agree on that. Gilad - I know you posted a patch, but, as Alon said, we can even support user@aaa@bbb, so supporting that might be problematic. In addition, don't see the added value in supporting that, so I'm closing this one as WONTFIX. > the native backend interface should always accept two fields: user name and > profile name in which user resides.
something related of us storing user name at cookie? 1. please explain why we store user name at cookie. 2. please explain why can't we acquire it from server when needed? it is accessible via http session, a simple query should be sufficient instead of filling browser cookie cache. 3. if it is required, why not store json or any decent format? a format that is deterministic encoding of to fields?
(In reply to Alon Bar-Lev from comment #11) > something related of us storing user name at cookie? > > 1. please explain why we store user name at cookie. > 2. please explain why can't we acquire it from server when needed? it is > accessible via http session, a simple query should be sufficient instead of > filling browser cookie cache. > 3. if it is required, why not store json or any decent format? a format that > is deterministic encoding of to fields? I'm sorry, that wasn't my impressions when reading your comments. Anyway, that's a regression, afaik you must fix a regression bug, so you can't 'leave' it..
(In reply to Gilad Chaplik from comment #12) > (In reply to Alon Bar-Lev from comment #11) > > something related of us storing user name at cookie? > > > > 1. please explain why we store user name at cookie. > > 2. please explain why can't we acquire it from server when needed? it is > > accessible via http session, a simple query should be sufficient instead of > > filling browser cookie cache. > > 3. if it is required, why not store json or any decent format? a format that > > is deterministic encoding of to fields? > > I'm sorry, that wasn't my impressions when reading your comments. > > Anyway, that's a regression, afaik you must fix a regression bug, so you > can't 'leave' it.. Can we have decent discussion, in which you help other people to understand the problem?
> Anyway, that's a regression, afaik you must fix a regression bug, so you > can't 'leave' it.. why we're not having a decent discussion? my problem remains, right from the title, you cannot type 'admin@internal' anymore.
(In reply to Gilad Chaplik from comment #14) > > Anyway, that's a regression, afaik you must fix a regression bug, so you > > can't 'leave' it.. > > why we're not having a decent discussion? > > my problem remains, right from the title, you cannot type 'admin@internal' > anymore. what problem? what is the sequence of reproduction? what the cookie is used for? refer to comment#11 and answer all questions. this ping pong and partial replies are not productive. think of us the most stupid people and try to explain a step by step description of the entire sequence, what used to work, what fails to work and the reasoning behind. bugzilla is not irc.
Created attachment 914984 [details] auto fill
(In reply to Alon Bar-Lev from comment #15) > (In reply to Gilad Chaplik from comment #14) > > > Anyway, that's a regression, afaik you must fix a regression bug, so you > > > can't 'leave' it.. > > > > why we're not having a decent discussion? > > > > my problem remains, right from the title, you cannot type 'admin@internal' > > anymore. > > what problem? what is the sequence of reproduction? what the cookie is used > for? refer to comment#11 and answer all questions. this ping pong and > partial replies are not productive. think of us the most stupid people and > try to explain a step by step description of the entire sequence, what used > to work, what fails to work and the reasoning behind. > > bugzilla is not irc. Got you, I will try :-) See attached image in comment 16: The inputs are in yellow (done by chrome), I've just clicked on user's input, and then the browser suggested me several users+pw in a hovering dropdown (unfortunately I cant prtscn it). without having heuristic (in client or backend), or somekind of cookie, we can't use this option, means we need to fill-in the domain by ourselves. now to questions: > something related of us storing user name at cookie? no, the browser does it. > > 1. please explain why we store user name at cookie. same. > 2. please explain why can't we acquire it from server when needed? it is > accessible via http session, a simple query should be sufficient instead of > filling browser cookie cache. same. > 3. if it is required, why not store json or any decent format? a format that > is deterministic encoding of to fields? same. I think I've talked about it in exposing bookmarks in REST, we don't need to do what browser gives us for free.
OK, so I will try to re-phrase. The auto-completion of the browser is comfortable for you to perform login. And you used to write user@PROFILE to perform shortcut of entering user and selecting a profile. When specifying @ at user name the Profile aka "Domain" becomes inactive, so someone thought it is usable and even adjusted UI. The problem that this is non deterministic, and use heuristics, as our user can contain any character, including '@'. I am for removing this option entirely, do not parse user name, always read profile selection. If truly important, I can accept a notation such as: "user"@"profile" The quotes will make the parsing deterministic.
(In reply to Alon Bar-Lev from comment #18) > OK, so I will try to re-phrase. > > The auto-completion of the browser is comfortable for you to perform login. > And you used to write user@PROFILE to perform shortcut of entering user and > selecting a profile. why you're referring me and not all users? ("... is comfortable for users to perform login, and users are used to..."). > > When specifying @ at user name the Profile aka "Domain" becomes inactive, so > someone thought it is usable and even adjusted UI. > > The problem that this is non deterministic, and use heuristics, as our user > can contain any character, including '@'. > > I am for removing this option entirely, do not parse user name, always read > profile selection. > > If truly important, I can accept a notation such as: > > "user"@"profile" strongly against that. > > The quotes will make the parsing deterministic. you can make it deterministic in so many other ways, and preserve this behavior, I gave several options in other thread (disallow "@admin" suffix, adding a "long flow" in the UI, etc.).
(In reply to Gilad Chaplik from comment #19) > (In reply to Alon Bar-Lev from comment #18) > > OK, so I will try to re-phrase. > > > > The auto-completion of the browser is comfortable for you to perform login. > > And you used to write user@PROFILE to perform shortcut of entering user and > > selecting a profile. > > why you're referring me and not all users? ("... is comfortable for users to > perform login, and users are used to..."). > you are a user, no? > > > > When specifying @ at user name the Profile aka "Domain" becomes inactive, so > > someone thought it is usable and even adjusted UI. > > > > The problem that this is non deterministic, and use heuristics, as our user > > can contain any character, including '@'. > > > > I am for removing this option entirely, do not parse user name, always read > > profile selection. > > > > If truly important, I can accept a notation such as: > > > > "user"@"profile" > > strongly against that. > > > > > The quotes will make the parsing deterministic. > > you can make it deterministic in so many other ways, and preserve this > behavior, I gave several options in other thread (disallow "@admin" suffix, > adding a "long flow" in the UI, etc.). no can do, @ within user name is mandatory to support.
> no can do, @ within user name is mandatory to support. if I'll add a check box that will be revealed only when "domains" is disabled, to enable it back (= not split the string), will it be sufficient to you?
(In reply to Gilad Chaplik from comment #21) > > no can do, @ within user name is mandatory to support. > > if I'll add a check box that will be revealed only when "domains" is > disabled, to enable it back (= not split the string), will it be sufficient > to you? this is the worse solution so far, what should the end-user understand from that? I do not understand why for this advanced feature the notation of "user"@"domain" is not sufficient. the browser will auto complete it and no issue with conflicts.
(In reply to Alon Bar-Lev from comment #22) > (In reply to Gilad Chaplik from comment #21) > > > no can do, @ within user name is mandatory to support. > > > > if I'll add a check box that will be revealed only when "domains" is > > disabled, to enable it back (= not split the string), will it be sufficient > > to you? > > this is the worse solution so far, what should the end-user understand from > that? the end user will not see the checkbox unless he will fill @XXX suffix in user input, and XXX will be a valid domain. we can add a nice caption that will explain it, it's not rocket science :-) > > I do not understand why for this advanced feature the notation of > "user"@"domain" is not sufficient. the browser will auto complete it and no > issue with conflicts. I think that this solution is competing for worst one alongside with mine's :-P
(In reply to Gilad Chaplik from comment #23) > > I do not understand why for this advanced feature the notation of > > "user"@"domain" is not sufficient. the browser will auto complete it and no > > issue with conflicts. > > I think that this solution is competing for worst one alongside with mine's > :-P A simple hint at user field that format is either user name or "user name"@"domain" will be sufficient, simple and without any magic, abnormal or exceptional behavior.
(In reply to Alon Bar-Lev from comment #24) > (In reply to Gilad Chaplik from comment #23) > > > I do not understand why for this advanced feature the notation of > > > "user"@"domain" is not sufficient. the browser will auto complete it and no > > > issue with conflicts. > > > > I think that this solution is competing for worst one alongside with mine's > > :-P > > A simple hint at user field that format is either user name or "user > name"@"domain" will be sufficient, simple and without any magic, abnormal or > exceptional behavior. I agree here. IMHO we have to distinguish between the user and profile with some special chararacter/s
you're missing the basic fact - that's a regression, and your solution doesn't fix it.
(In reply to Gilad Chaplik from comment #26) > you're missing the basic fact - that's a regression, and your solution > doesn't fix it. the "feature": specify profile and user name within user input, feature that is not documented, # of users that are aware of this is close to zero. the solution: use notation of "user"@"profile" instead of user@profile, add help hint at user box. the reasoning: enable deterministic algorithm, in dynamic environment in which user and profile can contain any character, especially '@'. the regression: minor format change, one time user modification (login). unless more productive comments this is what we are to do, the other option is disabling this "feature" completely. thank you for raising this issue.
(In reply to Alon Bar-Lev from comment #27) > (In reply to Gilad Chaplik from comment #26) > > you're missing the basic fact - that's a regression, and your solution > > doesn't fix it. > > the "feature": specify profile and user name within user input, feature that > is not documented, # of users that are aware of this is close to zero. > > the solution: use notation of "user"@"profile" instead of user@profile, add > help hint at user box. > Please add me as a reviewer to the patch, I'd like that the UI maintainer who acks it reads the bug. > the reasoning: enable deterministic algorithm, in dynamic environment in > which user and profile can contain any character, especially '@'. > > the regression: minor format change, one time user modification (login). > imo, changing "user@profile" to "user"@"profile" is wrong. the auto completion dropdown will still contain old values and we're just doubling its count. and I, as a user, can't get it (even if there's a hint). > unless more productive comments this is what we are to do, the other option > is disabling this "feature" completely. > > thank you for raising this issue. np :-) *** The bug: UI's bll splits login screen's user input to user and domain, according to first occurrence to '@' char; this feature is not documented; # of users that are aware of this is likely to be zero. the solution: http://gerrit.ovirt.org/#/c/29613/
(In reply to Gilad Chaplik from comment #28) > (In reply to Alon Bar-Lev from comment #27) > > (In reply to Gilad Chaplik from comment #26) > > > you're missing the basic fact - that's a regression, and your solution > > > doesn't fix it. > > > > the "feature": specify profile and user name within user input, feature that > > is not documented, # of users that are aware of this is close to zero. > > > > the solution: use notation of "user"@"profile" instead of user@profile, add > > help hint at user box. > > > > Please add me as a reviewer to the patch, I'd like that the UI maintainer > who acks it reads the bug. > > > the reasoning: enable deterministic algorithm, in dynamic environment in > > which user and profile can contain any character, especially '@'. > > > > the regression: minor format change, one time user modification (login). > > > > imo, changing "user@profile" to "user"@"profile" is wrong. the auto > completion dropdown will still contain old values and we're just doubling > its count. and I, as a user, can't get it (even if there's a hint). > > > unless more productive comments this is what we are to do, the other option > > is disabling this "feature" completely. > > > > thank you for raising this issue. > > np :-) > > *** > > The bug: UI's bll splits login screen's user input to user and domain, > according to first occurrence to '@' char; this feature is not documented; # > of users that are aware of this is likely to be zero. > > the solution: http://gerrit.ovirt.org/#/c/29613/ Gilad - I think that it may be a regression, but a regression that wasn't meant to be supported in the first place. It is not really user-friendly, and I wonder whether anyone uses it. The new changes we have made make it hacky to support this kind of input. And again, I don't see the use of that, given the fact that we have the profile list in the login page. Einav - I'm closing this one... if you think I'm wrong here, please reopen.
> Einav - I'm closing this one... if you think I'm wrong here, please reopen. Hi, We must take some form of action: if we do want to remove functionality, the logic of disabling the "Domain" drop box should be removed. if we want to keep functionality, we split based on quotes "user"@"profile". Gilad has a point, supporting this enable integration with browser's auto completion. Never used it my-self... but if that's is being used by a group of advanced users who are aware of the fact that user and profile can be specified at user field, then I do not mind to support that within deterministic notation, while these advanced users will should not mind much to add quotes if that's what they required. So I am reopening, and ask if we do want to support this or not, any answer will derive a patch. Thanks!
(In reply to Alon Bar-Lev from comment #30) > > Einav - I'm closing this one... if you think I'm wrong here, please reopen. > > Hi, > > We must take some form of action: > > if we do want to remove functionality, the logic of disabling the "Domain" > drop box should be removed. > Oh. I was sure it no longer disables the drop down list. My bad. If it is then we should remove it, imo. > if we want to keep functionality, we split based on quotes "user"@"profile". > > Gilad has a point, supporting this enable integration with browser's auto > completion. Never used it my-self... but if that's is being used by a group > of advanced users who are aware of the fact that user and profile can be > specified at user field, then I do not mind to support that within > deterministic notation, while these advanced users will should not mind much > to add quotes if that's what they required. > I think we should remove it, but let's see what Einav had in mind. > So I am reopening, and ask if we do want to support this or not, any answer > will derive a patch. > > Thanks!
I have to agree with Oved here - I think we should not support a "user"@"profile" notion: - I have never seen the "user"@"profile" notion used anywhere. - I believe that most users would prefer to select the Domain from the Domain drop-down, rather than type '"'s and '@'s. - The last-selected Domain is saved in a cookie, so the user won't need to re-select it on their second (and 3rd, and so on...) login. the only thing that the user will need to "worry about" is user-name and password, which are text-boxes; so for them - the auto-complete behavior of the browser will apply. - keeping it simple: no parsing in the GUI at all (to determine whether domain drop-down should be enabled/disabled, etc.), sending the values as-is to the engine, etc. to sum-up: we need to: - have the Domain drop-down *always* enabled. - send user, password, domain values to the engine as-is.
(In reply to Einav Cohen from comment #32) > I have to agree with Oved here - I think we should not support a > "user"@"profile" notion: > > - I have never seen the "user"@"profile" notion used anywhere. > > - I believe that most users would prefer to select the Domain from the > Domain drop-down, rather than type '"'s and '@'s. > > - The last-selected Domain is saved in a cookie, so the user won't need to > re-select it on their second (and 3rd, and so on...) login. the only thing > that the user will need to "worry about" is user-name and password, which > are text-boxes; so for them - the auto-complete behavior of the browser will > apply. > > - keeping it simple: no parsing in the GUI at all (to determine whether > domain drop-down should be enabled/disabled, etc.), sending the values as-is > to the engine, etc. > > to sum-up: we need to: > > - have the Domain drop-down *always* enabled. > > - send user, password, domain values to the engine as-is. Einav, this is no paper cut. A user will upgrade and then fail to login, same as happened to me. imo, at least we should support 'admin@internal' out of the box. Thanks.
(In reply to Gilad Chaplik from comment #33) > (In reply to Einav Cohen from comment #32) > > I have to agree with Oved here - I think we should not support a > > "user"@"profile" notion: > > > > - I have never seen the "user"@"profile" notion used anywhere. > > > > - I believe that most users would prefer to select the Domain from the > > Domain drop-down, rather than type '"'s and '@'s. > > > > - The last-selected Domain is saved in a cookie, so the user won't need to > > re-select it on their second (and 3rd, and so on...) login. the only thing > > that the user will need to "worry about" is user-name and password, which > > are text-boxes; so for them - the auto-complete behavior of the browser will > > apply. > > > > - keeping it simple: no parsing in the GUI at all (to determine whether > > domain drop-down should be enabled/disabled, etc.), sending the values as-is > > to the engine, etc. > > > > to sum-up: we need to: > > > > - have the Domain drop-down *always* enabled. > > > > - send user, password, domain values to the engine as-is. > > Einav, this is no paper cut. > > A user will upgrade and then fail to login, same as happened to me. > > imo, at least we should support 'admin@internal' out of the box. > > Thanks. Gilad, no matter which solution we will choose - admin@portal will not be supported anymore (or, more accurately, will be supported, however it will not be supported as user@domain, but as us@er). I think that enforcing the user to select a Domain in the drop-down (again - only once in their "lifetime", because we have a cookie) is the best and simplest solution - better than typing "xxx"@"yyy", checking a check-box or any other way which will complicate the login page beyond what it needs to be - a *simple* login page. thanks.
(In reply to Einav Cohen from comment #34) > (In reply to Gilad Chaplik from comment #33) > > (In reply to Einav Cohen from comment #32) > > > I have to agree with Oved here - I think we should not support a > > > "user"@"profile" notion: > > > > > > - I have never seen the "user"@"profile" notion used anywhere. > > > > > > - I believe that most users would prefer to select the Domain from the > > > Domain drop-down, rather than type '"'s and '@'s. > > > > > > - The last-selected Domain is saved in a cookie, so the user won't need to > > > re-select it on their second (and 3rd, and so on...) login. the only thing > > > that the user will need to "worry about" is user-name and password, which > > > are text-boxes; so for them - the auto-complete behavior of the browser will > > > apply. > > > > > > - keeping it simple: no parsing in the GUI at all (to determine whether > > > domain drop-down should be enabled/disabled, etc.), sending the values as-is > > > to the engine, etc. > > > > > > to sum-up: we need to: > > > > > > - have the Domain drop-down *always* enabled. > > > > > > - send user, password, domain values to the engine as-is. > > > > Einav, this is no paper cut. > > > > A user will upgrade and then fail to login, same as happened to me. > > > > imo, at least we should support 'admin@internal' out of the box. > > > > Thanks. > > Gilad, no matter which solution we will choose - admin@portal will not be > supported anymore (or, more accurately, will be supported, however it will > not be supported as user@domain, but as us@er). > I think that enforcing the user to select a Domain in the drop-down (again - > only once in their "lifetime", because we have a cookie) is the best and > simplest solution - better than typing "xxx"@"yyy", checking a check-box or > any other way which will complicate the login page beyond what it needs to > be - a *simple* login page. > thanks. @Einav, I disagree. imo, the simplest solution will be to merge my fix as it is- and forget about this bug/feature/whatnot to the next time someone does massive refactoring. @Oved, Can you please explain me why you think this bug isn't considered to be a regression?
(In reply to Gilad Chaplik from comment #35) > (In reply to Einav Cohen from comment #34) > > (In reply to Gilad Chaplik from comment #33) > > > (In reply to Einav Cohen from comment #32) > > > > I have to agree with Oved here - I think we should not support a > > > > "user"@"profile" notion: > > > > > > > > - I have never seen the "user"@"profile" notion used anywhere. > > > > > > > > - I believe that most users would prefer to select the Domain from the > > > > Domain drop-down, rather than type '"'s and '@'s. > > > > > > > > - The last-selected Domain is saved in a cookie, so the user won't need to > > > > re-select it on their second (and 3rd, and so on...) login. the only thing > > > > that the user will need to "worry about" is user-name and password, which > > > > are text-boxes; so for them - the auto-complete behavior of the browser will > > > > apply. > > > > > > > > - keeping it simple: no parsing in the GUI at all (to determine whether > > > > domain drop-down should be enabled/disabled, etc.), sending the values as-is > > > > to the engine, etc. > > > > > > > > to sum-up: we need to: > > > > > > > > - have the Domain drop-down *always* enabled. > > > > > > > > - send user, password, domain values to the engine as-is. > > > > > > Einav, this is no paper cut. > > > > > > A user will upgrade and then fail to login, same as happened to me. > > > > > > imo, at least we should support 'admin@internal' out of the box. > > > > > > Thanks. > > > > Gilad, no matter which solution we will choose - admin@portal will not be > > supported anymore (or, more accurately, will be supported, however it will > > not be supported as user@domain, but as us@er). > > I think that enforcing the user to select a Domain in the drop-down (again - > > only once in their "lifetime", because we have a cookie) is the best and > > simplest solution - better than typing "xxx"@"yyy", checking a check-box or > > any other way which will complicate the login page beyond what it needs to > > be - a *simple* login page. > > thanks. > > @Einav, I disagree. imo, the simplest solution will be to merge my fix as it > is- and forget about this bug/feature/whatnot to the next time someone does > massive refactoring. Why? This behavior is wrong. Why doing hacky patches to keep it? > > @Oved, Can you please explain me why you think this bug isn't considered to > be a regression? I don't think this functionality is important whatsoever. It makes the login page cumbersome... let's make stuff simple here. Supporting it so far is a bug.
> @Einav, I disagree. imo, the simplest solution will be to merge my fix as it > is- and forget about this bug/feature/whatnot to the next time someone does > massive refactoring. - I guess that we simply have different opinions regarding what is considered "simple". let's agree to disagree. - IIUC, your patch [http://gerrit.ovirt.org/#/c/29613] assumes that if a user writes a@b, and "b" is listed as a domain, you assume that the "b" within "a@b" is a domain, and not part of the user-name itself. this is not necessarily a correct assumption - what if the user name is a@b and the domain is b (so the full user@domain is actually a@b@b)? even if this is a corner case or even an impossible case (or even if I got your code wrong), the general approach of the GUI parsing the values, trying to heuristically make guesses and be "smarter" than it should be is wrong IMO.
Einav Yair/Ravi can do this if you have resource issues. It is our task... Not that I won't be happy if you guys do it :) Thanks!
(In reply to Alon Bar-Lev from comment #38) > Einav Yair/Ravi can do this if you have resource issues. It is our task... > Not that I won't be happy if you guys do it :) > Thanks! Thanks Alon, it is a pure GUI task (or, "worst" case, almost a pure GUI task), and not a large one anyway IIUC. leaving it on Greg.
Greg, any eta?
I should be able to post a patch today or tomorrow.
While working on this, I noticed there are other places where this needs to be addressed -- for example, when sending login information to a vm. This will need its own BZ. See comments in http://gerrit.ovirt.org/#/c/31792/ for more info.
(In reply to Greg Sheremeta from comment #42) > While working on this, I noticed there are other places where this needs to > be addressed -- for example, when sending login information to a vm. This > will need its own BZ. > > See comments in http://gerrit.ovirt.org/#/c/31792/ for more info. done, bug#1133137, thanks!
Domain dropdown is not blanked. userName part is taken as only username without domain part even when username has '@' in username.
oVirt 3.5 has been released and should include the fix for this issue.