Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
<jweiss> thomasmckay: looks like API can still create users without default
org/env: [10:20]
<jweiss>
https://katello-ci-rhel6.usersys.redhat.com/katello/users#panel=user_2
<jweiss> is that a problem?
<thomasmckay> jweiss: in my mind this should still be allowed, though perhaps
product people might disagree? [10:21]
<thomasmckay> in any case, yes that was purposefully left to be allowed
<jweiss> thomasmckay: why would the UI disallow it?
[10:22]
<thomasmckay> because it would be best practice :) i was going by the rule of
thumb, "the ui doesn't have to do everything the command line
can, but it can't do more"
<thomasmckay> feel free to BZ it and broader audience can discuss [10:23]
<jweiss> thomasmckay: it's not a big deal, but what i'd expect is enforcement
of required fields would be done below the level of the gui/api
interfaces [10:24]
<jweiss> the ui could support that, but i wouldn't expect it to do enforcement
where the model does not [10:25]
<jweiss> maybe there are already other places in the ui that do this, but i
don't know of any
<thomasmckay> jweiss: valid point. BZ and i will make it optional [10:26]
<jweiss> thomasmckay: what happens to users who don't have org/env? [10:29]
<jweiss> what are those fields used for?
<thomasmckay> those are just used when a system is registered
<jweiss> and if the user doesn't have a default, the system that's registering
has to specify? [10:30]
<thomasmckay> if org/env is not specified explicitly, then they are required
to be passed in
<jweiss> i see
<thomasmckay> and on older sub-mgr there are no options for env/org so those
systems could not be registered w/o the user specified having
defaults
Version-Release number of selected component (if applicable):
katello-0.1.101-1.git.29.06e63e6.el6.x86_64
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Specifying a default env is not required for neither orgs nor users.
commit 675939678e3029f1648a3ee35e0dfa8644c9130b
Merge: bd2823b 0220075
Author: Tom McKay <thomasmckay>
Date: Mon Nov 14 08:43:22 2011 -0500
Description of problem: <jweiss> thomasmckay: looks like API can still create users without default org/env: [10:20] <jweiss> https://katello-ci-rhel6.usersys.redhat.com/katello/users#panel=user_2 <jweiss> is that a problem? <thomasmckay> jweiss: in my mind this should still be allowed, though perhaps product people might disagree? [10:21] <thomasmckay> in any case, yes that was purposefully left to be allowed <jweiss> thomasmckay: why would the UI disallow it? [10:22] <thomasmckay> because it would be best practice :) i was going by the rule of thumb, "the ui doesn't have to do everything the command line can, but it can't do more" <thomasmckay> feel free to BZ it and broader audience can discuss [10:23] <jweiss> thomasmckay: it's not a big deal, but what i'd expect is enforcement of required fields would be done below the level of the gui/api interfaces [10:24] <jweiss> the ui could support that, but i wouldn't expect it to do enforcement where the model does not [10:25] <jweiss> maybe there are already other places in the ui that do this, but i don't know of any <thomasmckay> jweiss: valid point. BZ and i will make it optional [10:26] <jweiss> thomasmckay: what happens to users who don't have org/env? [10:29] <jweiss> what are those fields used for? <thomasmckay> those are just used when a system is registered <jweiss> and if the user doesn't have a default, the system that's registering has to specify? [10:30] <thomasmckay> if org/env is not specified explicitly, then they are required to be passed in <jweiss> i see <thomasmckay> and on older sub-mgr there are no options for env/org so those systems could not be registered w/o the user specified having defaults Version-Release number of selected component (if applicable): katello-0.1.101-1.git.29.06e63e6.el6.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: