|Summary:||Ordinary users cannot see system they have just registered|
|Product:||Red Hat Satellite 5||Reporter:||Nick Strugnell <nstrug>|
|Component:||Server||Assignee:||Nick Strugnell <nstrug>|
|Status:||CLOSED NOTABUG||QA Contact:||Fanny Augustin <fmoquete>|
|Version:||unspecified||CC:||godfrey.paul, liocourt, pcfe, rhn-bugs|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-04-30 19:59:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Nick Strugnell 2004-02-19 14:10:34 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 Description of problem: When an ordinary user registers a system using rhn_register, they will not have access to the new system on the satellite. This is because a new system is 'ungrouped' and as ordinary users only have access to their assigned groups, they will not have access to it. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. As org admin, create a user 2. Assign the user to some groups 3. As the user, register a new system Actual Results: The new system does not appear on the user's 'Systems' page Expected Results: Ideally, the system should appear in an 'Ungrouped' category, visible by the user. Additional info: Can be worked around by only allowing users to use activation keys to register systems into their groups. However, the activation keys can only be created by org admins, and this creates a management problem in large orgs.
Comment 1 Mihai Ibanescu 2004-02-19 18:13:16 UTC
There is a better workaround for that. As an org admin, create an activation key and have: Universal default: Yes, use this token for all normal registrations You can attach groups to this "global" registration token; all systems will land into this group. One can probably grant access to all users into this "New Systems" group. Let me know if this helps solve your problem.
Comment 2 Nick Strugnell 2004-02-20 09:27:14 UTC
The problem with this workaround is that the individual users cannot then move the systems into their own groups - see #116420.
Comment 3 Mihai Ibanescu 2004-02-20 13:13:36 UTC
Reassigning to Robin - he may have something more clever to say :-)
Comment 4 Robin Norwood 2004-02-20 14:24:48 UTC
Nick, On the RHN site, go to the 'Users' tab, select a user, and click the 'System Groups' tab of the user details page. The 'Default System Groups' feature is the one you are looking for, I believe. Activation keys is another way to solve this problem - you can specify system groups for an activation key, and a system registered with that key will be placed in those groups. The user must also have permission to the groups for him to see the systems.
Comment 5 Robin Norwood 2004-02-20 14:25:15 UTC
Let me know if the above solution meets your needs.
Comment 6 Nick Strugnell 2004-03-15 17:11:26 UTC
The ideal situation would be a user would register a system into a default group e.g. 'Newly Registered Systems'. This can be done using the default system groups or activation keys. The user would then move the system to the final destination group - this is the bit that we cannot do at present.
Comment 7 Greg DeKoenigsberg 2004-04-30 19:59:41 UTC
Nick, This is not a bug; it's a design decision. Therefore I'm closing it, but with this final workaround: * Create a group for each user. Let's say you've got three users: Adam, Bob, and Charlie. One group for each: "Adam's new systems, Bob's new systems, Charlie's new systems." * Create activation keys for each. When Adam uses "Adam's key," it'll put the new system into "Adam's new systems". * Adam, Bob, and Charlie will have the ability to reassign any systems that come into these groups into any other groups to which they have admin access. Therefore, Charlie should be able to move a new system from "Charlie's new systems" into "Charlie's web servers". NOTE: there will be a feature forthcoming that allows users to use multiple activation keys together; this feature will allow you to have an "Adam/Bob/Charlie" key that can be combined with other keys that govern other attributes. This should be customer-facing within the next 6-8 weeks. Hope this helps.