Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Hudson-ci/features/Team Concept"
m |
|||
Line 1: | Line 1: | ||
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 | ||
− | + | == Concept<br> == | |
+ | '''System admin '''<br> === | ||
− | + | 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> | |
− | * | + | *Responsible to set up team and adding a team admin<br> |
+ | *Other higher level administration like installing plugin | ||
+ | *<br> | ||
− | + | === '''Team Admin'''<br> === | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | 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<br> | |
− | + | *Add and remove team members | |
− | + | *<br> | |
− | + | ||
− | + | === '''Team member '''<br> === | |
− | + | Each team will have one or more members. The authorizations are<br> | |
− | + | ||
− | + | ||
− | * | + | *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<br> | ||
+ | |||
+ | === Authorization Schemes<br> === | ||
+ | |||
+ | The three authorization schemes are<br> | ||
+ | |||
+ | #System Admin Authorization | ||
+ | #Team Admin Authorization | ||
+ | #Team Member Authorization<br> | ||
+ | |||
+ | === Job scope === | ||
+ | |||
+ | There are two scopes <br> | ||
+ | |||
+ | '''Public Scope'''<br> | ||
+ | |||
+ | *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 team members can view team private jobs | ||
#Only certain team members can manually run | #Only certain team members can manually run | ||
#Only certain team members can edit configuration | #Only certain team members can edit configuration | ||
#Only certain team members can delete job | #Only certain team members can delete job | ||
− | #Only certain team members can delete job build | + | #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. Anonymous users can view jobs only allowed to view as public <br> | |
− | + | | |
− | + | ||
− | + | == Capabilities == | |
{| width="800" cellspacing="1" cellpadding="1" border="1" | {| width="800" cellspacing="1" cellpadding="1" border="1" | ||
Line 105: | Line 126: | ||
|} | |} | ||
− | '''Legend:'''<br> | + | '''Legend:'''<br> |
− | {| width="650" | + | {| width="650" cellspacing="1" cellpadding="1" border="1" |
− | | '''Scope''' | + | |- |
+ | | '''Scope''' | ||
| '''Means''' | | '''Means''' | ||
|- | |- | ||
− | | Y | + | | Y |
| All teams | | All teams | ||
|- | |- | ||
− | | - | + | | - |
| Not allowed | | Not allowed | ||
|- | |- | ||
− | | Team | + | | Team |
| Only within the same team | | Only within the same team | ||
|- | |- | ||
− | | <Team> | + | | <Team> |
| Only within the same team if capability granted by system or team admin | | Only within the same team if capability granted by system or team admin | ||
|- | |- | ||
− | | Self-created | + | | Self-created |
| Only if created by that team member | | Only if created by that team member | ||
|} | |} | ||
Line 133: | Line 155: | ||
*Build History should show only the jobs accessible to the current user | *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 | *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 |
*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 | ||
== Desirable Features (For Discussion) == | == 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. | + | *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> |
Revision as of 21:47, 23 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
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
- Responsible to set up team and adding a team admin
- Other higher level administration like installing plugin
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
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 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 | - |
See 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 |
Additional Requirements
- 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
- 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.