The idea is to implement the concept of team so that several authentication and authorization can be assigned to that team. This helps multiple software project teams can use a single Hudson, but each team won't mess with other teams jobs. See also the Team Concept User view page.
Every Hudson instance will have at least one Sys Admin. Each Sys Admin will have Hudson wide authorization. Some of the main responsibilities are
- Set up team and adding a team admin
- All higher level administrations like installing plugin, setting up security, and configuring the system
Every team will have at least one team admin . Team admin has less power. Each Team Admin will have team wided authorization. Some of the main responsibilities are
- Add and remove team members
- Setting permission for team members
Each team will have one or more members. The authorizations are
- Can create and configure job if team admin admits
- Can set a job as public so that other teams can see it
- Can delete any job if team admin admits or only delete the self created job
- Can delete any job builds if team admin admits or only delete the self created job builds
- Can run any team job and public job
The three authorization schemes required are
- System Admin Authorization
- Team Admin Authorization
- Team Member Authorization
There are two scopes
- Any one can view this job
- Only Sys Admin can delete this job
- Only Sys Admin can configure this job
- Only Sys Admin can run this job
- Only team members can view team private jobs
- Only certain team members can manually run
- Only certain team members can edit configuration
- Only certain team members can delete job
- Only certain team members can delete job build
The visibility of a job can be set to
- Any one can view this job
- Only members can configure, run and delete the job
- Only visible to team members
Particular team can only view their jobs and any public jobs. Anonymous users can view jobs only allowed to view as public
|Capability||System Admin||Team Admin||Team Member|
|Create system admin||Y||-||-|
|Create team admin||Y||Team||-|
|Create team member||Y||Team||-|
|View team job||Y||Team||Team|
|Create team job||Y||Team||<Team>|
|Delete team job||Y||Team||Self-created or <Team>|
|Configure team job||Y||Team||Self-created or <Team>|
|Run team job||Y||Team||Self-created or <Team>|
|Set team job public||Y||Team||<Team>|
|Team||Only within the same team|
|<Team>||Only within the same team if capability granted by system or team admin|
|Self-created||Only if created by that team member|
- Team concept must be implemnted as an Authorization scheme and easily switchable to other authorization scheme
- Multiple teams must be able to use same name for a job.
- Jobs must be saved in team specific folders
- Build History should show only the jobs accessible to the current user
- The people dashboard should display only the team members of the current user
- Build executor status must display jobs of the current user team
- If a team is deleted, then all its jobs must become global jobs, so that System Admin can assign them to other teams
- When switching between Team administration to/from standard or no administration data (jobs) must not be lost
- It would be good if team configurations were preserved even when team feature is not active. Currently, toggling security or switching security realms or authorization methods does not preserve previous configuration data. However, the investment in team configuration is liable to be substantial and responsibility divided among multiple people; it could be very difficult to recover manually.
In order to support jobs with same name on multiple teams, all jobs are associated with an id. The is a fully qualified name "team.jobName" for team jobs or "jobName" for public (non-team or team sysAdmin) jobs. So the URL would look like the following
When the Team Manager is enabled, all job names used in Command Line, must have the fully qualified Name (Eg. myTeam.myJob) for team jobs or unqualified name (e.g., myJob) for public jobs.
Use of may in the following indicates a proposal is on the table but no final decision has been made.
No job id
The job id has been removed. Job id and team id no longer appear in a job's config file.
The job name of a team job (except for the public team) is
team-name is the name of the team and
job-part is the part of the job name that is unique within the team. For a public job, the
team-name. is omitted; only the
job-part is used. The entire job name must, of course, be globally unique.
'.' (dot/period) used to separate the parts of a team job name is not a reserved character. It may appear in the names of public jobs and elsewhere in the names of team jobs. Dot is chosen because it is a conventional namespace separator character. However, the presence of a dot does not, of itself, identify the job as belonging to a namespace. Only the creation of a job in a specific team does that; the name follows the membership, not vice versa.
The only two places in the UI where the job name appears as
job-part without the team qualifier are in the New Job and Configure Job pages. Both of these are edit contexts; in the latter, an edit causes a job rename.
To minimize confusion, a check may be added to New Job to discourage names with extra dots, but that would restrict the user while not preventing the creation of such jobs by other means.
Public jobs are folders in
HUDSON_HOME/jobs/job-name. Team jobs are folders in
HUDSON_HOME/teams/team-name/job-name. This addresses a user requirement that files for a particular team be isolated to a single folder.
There may be an option to co-locate a team job with public jobs, in
HUDSON_HOME/jobs/job-name. The option would be set when a job is created. There may be a way to change the default of this option in the Hudson system configuration. Turning co-locate on makes it more likely that plugins that examine job files or back them up continue to work without modification. Turning it off satisfies the separate folder requirement, which not all users may have. The option would pave the way for entirely user-configurable individual job location, not contemplated in this release.
Formerly TeamManager was only available when team was enabled. To allow team jobs to be visible and usable even if team is temporarily disabled - a user requirement - the TeamManager will be available and active at all times, independent of whether team validation is in use. If team validation is disabled, it will behave as if all users are members of the public team. Otherwise, it will assign users to their correct team(s).
You may be wondering how, if the team namespace qualification in a job name is not reserved and team jobs might appear in different locations depending on configuration, how are team jobs located? When any job is created, it is assigned to the current user's team. When a job is loaded or saved, Hudson asks the TeamManager and uses the location assigned to the team.
There are two exceptions to this rule:
- A user may be a member of more than one team.
- The sys admin user is considered to be a member of all teams, including the public team.
To deal with this, two changes may be required:
- The New Job page may have an option to select a team in either of these cases.
- The CLI commands dealing with job management may have an added, optional argument to designate a target team.
Public Means Public
Any user, even the anonymous user, can see public jobs, their build status and history, build logs, etc. Anonymous users, however, cannot configure the jobs or start a build.
If you don't like this behavior and want to keep all team jobs private, you can create a team, e.g., named
Shared, and make all users members of the shared team. If the Shared team has no admins, only the sys admin will be able to manage jobs in
This scheme can be generalized to multiple groups of teams; each group can have their own shared group which is not visible to other groups.