Difference between revisions of "Hudson-ci/features/Team Concept"

From Eclipsepedia

Jump to: navigation, search
m (New page: Feature: Team concept 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 t...)
 
(23 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Feature: Team concept
+
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 [http://wiki.eclipse.org/Hudson-ci/features/Team_Concept_User_View Team Concept User view] page.
  
  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
+
== Concept<br>  ==
  
The tasks are
+
=== '''System admin '''<br>  ===
  
    Implement the concept of System admin and team 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<br>
        System admin are responsible for
+
 
            Setting up team and adding a team admin
+
*Set up team and adding a team admin<br>
            Hudson wide Authentication
+
*All&nbsp; higher level administrations like installing plugin, setting up security, and configuring the system<br>
            Other higher level administration like installing plugin
+
 
            Assign public jobs (with no associated teams) to specific teams
+
=== '''Team Admin'''<br>  ===
            Every hudson will have at least System admin
+
 
        Team admin has less power
+
Every team will have at least one team admin . Team admin has less power. Each Team Admin will have team wided authorization.&nbsp; Some of the main responsibilities are<br>
            Every team will have at least one team admin
+
 
            Add and remove team members
+
*Add and remove team members  
            Authorize user permission such as which member can edit job, delete job etc
+
*Setting permission for team members<br>
        Team member
+
 
            Can create and configure job if team admin admits
+
=== '''Team member '''<br>  ===
            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
+
Each team will have one or more members.&nbsp; The authorizations are<br>
            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
+
*Can create and configure job if team admin admits  
    Implement Permisson Scheme
+
*Can set a job as public so that other teams can see it  
        System Admin Permission
+
*Can delete any job if team admin admits or only delete the self created job  
        Team Admin Permission
+
*Can delete any job builds if team admin admits or only delete the self created job builds  
        Team Member Permission
+
*Can run any team job and public job<br>
    Implement the concept of Groups
+
 
        group can have any user as member
+
=== Authorization&nbsp; Schemes<br>  ===
        Any group can be assigned with certain permission
+
 
        (Ex. system-admin group can be assigned with System Admin permission )
+
The three authorization schemes&nbsp; required are<br>
    Implement the concept of job permission
+
 
        Global jobs - any one can view
+
*System Admin Authorization
        Team jobs
+
*Team Admin Authorization
            Only team members can view team private jobs
+
*Team Member Authorization<br>
            Only certain team members can manually run
+
 
            Only certain team members can edit configuration
+
=== Job scope  ===
            Only certain team members can delete job
+
 
            Only certain team members can delete job build
+
There are two scopes <br>
    Implement project view based on team authorization
+
 
        Particular team can only view their jobs and any public jobs
+
'''Public Scope'''<br>
        Anonymous users can view jobs only allowed to view as public
+
 
 +
*Any one can view this job <br>
 +
*Only Sys Admin can delete this job<br>
 +
*Only Sys Admin can configure this job<br>
 +
*Only Sys Admin can run this job<br>
 +
 
 +
'''Team Scope'''<br>
 +
 
 +
*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<br>
 +
 
 +
=== Job Visibility<br>  ===
 +
 
 +
The visibility of a job can be set to<br>
 +
 
 +
'''public '''<br>
 +
 
 +
*Any one can view this job<br>
 +
*Only members can configure, run and delete the job<br>
 +
 
 +
'''Team private'''<br>
 +
 
 +
*Only visible to team members<br>
 +
 
 +
Particular team can only view their jobs and any public jobs.&nbsp; Anonymous users can view jobs only allowed to view as public <br>
 +
 
 +
&nbsp;
 +
 
 +
== Capabilities  ==
 +
 
 +
{| width="800" cellspacing="1" cellpadding="1" border="1"
 +
|-
 +
| '''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
 +
| &lt;Team&gt;
 +
|-
 +
| Delete team job
 +
| Y
 +
| Team
 +
| Self-created or &lt;Team&gt;
 +
|-
 +
| Configure team job
 +
| Y
 +
| Team
 +
| Self-created or &lt;Team&gt;
 +
|-
 +
| Run team job
 +
| Y
 +
| Team
 +
| Self-created or &lt;Team&gt;
 +
|-
 +
| Set team job public
 +
| Y
 +
| Team
 +
| &lt;Team&gt;
 +
|}
 +
 
 +
'''Legend:'''<br>
 +
 
 +
{| width="650" cellspacing="1" cellpadding="1" border="1"
 +
|-
 +
| '''Scope'''
 +
| '''Means'''
 +
|-
 +
| Y
 +
| All teams
 +
|-
 +
| -
 +
| Not allowed
 +
|-
 +
| Team
 +
| Only within the same team
 +
|-
 +
| &lt;Team&gt;
 +
| 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.<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.

Contents

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


TeamJobAcessUrl.png


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