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

+

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.&nbsp; See also the [http://wiki.eclipse.org/Hudson-ci/features/Team_Concept_User_View Team Concept User view] page.

== Concept<br> ==

== Concept<br> ==

Line 149:

Line 149:

|}

|}

−

== Additional Requirements ==

+

== Requirements ==

+

*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.

*Multiple teams must be able to use same name for a job.

*Jobs must be saved in team specific folders

*Jobs must be saved in team specific folders

Line 156:

Line 157:

*The people dashboard should display only the team members of 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

*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

*When switching between Team administration to/from standard or no administration data (jobs) must not be lost

Line 161:

Line 163:

*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.<br>

*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.<br>

+

+

+

+

== Implementation Note ==

+

+

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". So the URL would look like the following

+

+

+

+

[[Image:TeamJobAcessUrl.png]]

+

+

+

+

When the Team Manager is enabled, all job names used in Command Line, must have the fully qualified Name (Eg. myTeam.myJob)

Revision as of 21:34, 28 May 2013

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.

Concept

System admin

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

Team Admin

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

Team member

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

Authorization Schemes

The three authorization schemes required are

System Admin Authorization

Team Admin Authorization

Team Member Authorization

Job scope

There are two scopes

Public Scope

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

Team Scope

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

Job Visibility

The visibility of a job can be set to

public

Any one can view this job

Only members can configure, run and delete the job

Team private

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

Capabilities

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>

Legend:

Scope

Means

Y

All teams

-

Not allowed

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

Requirements

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

Desirable Features (For Discussion)

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.

Implementation Note

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". 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)