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):
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
Expected Results: Ideally, the system should appear in an 'Ungrouped'
category, visible by the user.
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.
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.
The problem with this workaround is that the individual users cannot
then move the systems into their own groups - see #116420.
Reassigning to Robin - he may have something more clever to say :-)
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.
Let me know if the above solution meets your needs.
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.
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.