+ Software supply chain management done right ! +
+ ++ SW360 is an open source software project licensed under the EPL-2.0 that + provides both a web application and a repository to collect, organize and + make available information about software components. It establishes a + central hub for software components in an organization. +
++$ mvn versions:set -DnewVersion=1.2.0 +$ git add pom.xml **/pom.xml +$ git commit -sS -m "chore(release): set version to 1.2.0" ++This will actually edit all pom.xml files and change the versions to **1.2.0**. + +### 2. Test the project +```shell +$ mvn install +``` + +### 3. Create and push the tag +```shell +$ mvn scm:tag +``` +This creates the tag and **pushes it to GitHub**. + +-- +⁽¹⁾ based on: https://axelfontaine.com/blog/final-nail.html diff --git a/content/fr/docs/Development/Dev-Role-Authorisation-Model.md b/content/fr/docs/Development/Dev-Role-Authorisation-Model.md new file mode 100644 index 0000000..6efc08e --- /dev/null +++ b/content/fr/docs/Development/Dev-Role-Authorisation-Model.md @@ -0,0 +1,126 @@ +--- +title: "Roles and Authorization" +linkTitle: "Roles and Authorization" +weight: 10 +description: "SW360 Roles and Authorization" +--- + +Like any other system, SW360 allows for setting different levels of access for different users. Technically, the decision when user should be able to see or to do something happens (generally) on the backend server. This ensures consistency between the REST API and the portal application. + +For setting roles of a user, the Liferay control panel is being used (Admin menu -> Control Panel -> Users and Organisations -> Users -> select one user and Edit -> Roles). Setting access at individual records happens in the edit view of that record. + +## Roles Overview + +SW360 offers two choices for doing the roles: one is setting access rights at every record individually. Another are general roles that can be set for every user. An admin of SW360 can set user roles at the Liferay Users and Roles UI. + +#### Setup Admin (Liferay Role) + +The setup admin is the Liferay administrator, which can configure the entire liferay app, such as which portlets are shown on which page. + +#### SW360 Admin (Liferay Role) + +The SW360 admin can change all data and promote users for more access rights, such as promoting a user to role `CLEARING_ADMIN`. This role can change data from other groups, limited by visibility setting of a project. + +#### Clearing Admin (Liferay Role) + +The clearing admin can change all component and release records and project records of the same group. This can be seen as group administrator. + +#### Security Admin (Liferay Role) + +In addition to the user rights, the security admin can set security vulnerabilities to irrelevant + +#### ECC Admin (Liferay Role) + +In addition to the user rights, the ECC admin can manipulate ECC data. + +#### User + +A user can create, modify and delete all own (=self created) records. A user cannot change records of others + +### Moderation Requests + +If a user with user or other access role rights is not entitled to write or change a record, a moderation request will be created. The moderation request contains the changes an will be routed for approval to the users who can write this record. + +In addition there are ACL-style roles, meaning that per data item access settings can be made: + +1. **creator** - a creator can modify in addition to the user's read abilities, a user can be creator of a data item +2. **moderator** - a creator can define moderators for a data item. Moderators can change a data item as a creator can. +3. **contributor** (Component) - is a contributor to a component, project, similar (but not the same) to a moderator. In addition to moderator, this role has been added to identify contributors (or that contributors get the fame). +In contrast, the contributor cannot delete data items. +5. **project responsible** (Project) - is a contributor, just named differently to identify the responsible person. +6. **lead architect** (Project) - is a contributor, just named differently to identify the responsible person. an architect refers to the person who has that role of the project or product. This role has been added to identify architects to have a contact person for technical questions. +7. **contact** (Release) - deprecated, should be renamed to contributor see #100. + +`group (department)`, `contributor`, `moderator` and `owner` roles are entity specific, `user`, `clearing admin` and `admin` are roles assigned to a user. + +### Additional Project Visibility + +In addition to the roles mentioned above, each project has a separate visibility setting (technically an attribute of the project document). There are four project visibility levels: + +1. Private - no one but the creator can read. +2. Me and moderators - involves all moderators and contributors, basically all names that are named among the attributes (lead architect, project responsible, contributors) +3. Department / business unit (should be renamed) - refer to the group the users are in. +4. Public - all registered users of the liferay / sw360 application (login required). + +The access rules are implemented in`lib-datahandler`. In the package, `com.siemens.sw360.datahandler.permissions` this is implemented in `ProjectPermissions`. See methods `isVisible` and `userIsEquivalentToModeratorinProject()` for the actual rules. + +### Overall Access Matrix + +The following table presents the SW360 Role-Authorisation-Model. + +The row specifies which action to take, the column the role of the actor. Cell entries specify which entity type can be acted upon. + +| | creator | moderator | contributor | user | clearing admin | (sw360)admin | +| --- | ----------- | --------- | ----- | ---- | -------- | ----- | +| create | - | - | - | PCRV | PCRVL | PCRVL | +| read | P | P | P | (P²)CRVL | (P²)CRVL | PCRVL | +| edit | PCR | PCR | PCR | (all created ones) | PCRVL | PCRVL | +| delete | PCR | PCR | - | (all created ones) | L | PCRVL | + +P² : only if the user is member of the group of the project (or has created the project) + +Note that ECC Admins and Security Admins have only the ability to write ECC and security data respectively at given records. However, as for the other access rights this role does not enhance anything above users. + +#### Legend + +| acronym | description | +| ------- | ----------- | +| P | project | +| C | component| +| R | release | +| V | vendor | +| L | license | + +## Technical Info + +The role access rules are put into `lib-datahandler`. In the package, `com.siemens.sw360.datahandler.permissions` there are implementing classes of a template class `DocumentPermissions`. As an example, `ProjectPermissions` extends abstract class `DocumentPermissions`. + +At run time, a permissions object consisting of a document and a user is created: In `PermissionUtils` (same package) there is a static method `makePermissions
+ ソフトウェアサプライチェーン管理の決定版！ +
+ ++ SW360はEPL-2.0ライセンスのオープンソースソフトウェアプロジェクトであり、ソフトウェアコンポーネントに関する情報を収集、整理し、利用可能にするウェブアプリケーションとリポジトリを提供します。組織内のソフトウェアコンポーネントの中央ハブを確立します。 +
++$ mvn versions:set -DnewVersion=1.2.0 +$ git add pom.xml **/pom.xml +$ git commit -sS -m "chore(release): set version to 1.2.0" ++This will actually edit all pom.xml files and change the versions to **1.2.0**. + +### 2. Test the project +```shell +$ mvn install +``` + +### 3. Create and push the tag +```shell +$ mvn scm:tag +``` +This creates the tag and **pushes it to GitHub**. + +-- +⁽¹⁾ based on: https://axelfontaine.com/blog/final-nail.html diff --git a/content/ja/docs/Development/Dev-Role-Authorisation-Model.md b/content/ja/docs/Development/Dev-Role-Authorisation-Model.md new file mode 100644 index 0000000..6efc08e --- /dev/null +++ b/content/ja/docs/Development/Dev-Role-Authorisation-Model.md @@ -0,0 +1,126 @@ +--- +title: "Roles and Authorization" +linkTitle: "Roles and Authorization" +weight: 10 +description: "SW360 Roles and Authorization" +--- + +Like any other system, SW360 allows for setting different levels of access for different users. Technically, the decision when user should be able to see or to do something happens (generally) on the backend server. This ensures consistency between the REST API and the portal application. + +For setting roles of a user, the Liferay control panel is being used (Admin menu -> Control Panel -> Users and Organisations -> Users -> select one user and Edit -> Roles). Setting access at individual records happens in the edit view of that record. + +## Roles Overview + +SW360 offers two choices for doing the roles: one is setting access rights at every record individually. Another are general roles that can be set for every user. An admin of SW360 can set user roles at the Liferay Users and Roles UI. + +#### Setup Admin (Liferay Role) + +The setup admin is the Liferay administrator, which can configure the entire liferay app, such as which portlets are shown on which page. + +#### SW360 Admin (Liferay Role) + +The SW360 admin can change all data and promote users for more access rights, such as promoting a user to role `CLEARING_ADMIN`. This role can change data from other groups, limited by visibility setting of a project. + +#### Clearing Admin (Liferay Role) + +The clearing admin can change all component and release records and project records of the same group. This can be seen as group administrator. + +#### Security Admin (Liferay Role) + +In addition to the user rights, the security admin can set security vulnerabilities to irrelevant + +#### ECC Admin (Liferay Role) + +In addition to the user rights, the ECC admin can manipulate ECC data. + +#### User + +A user can create, modify and delete all own (=self created) records. A user cannot change records of others + +### Moderation Requests + +If a user with user or other access role rights is not entitled to write or change a record, a moderation request will be created. The moderation request contains the changes an will be routed for approval to the users who can write this record. + +In addition there are ACL-style roles, meaning that per data item access settings can be made: + +1. **creator** - a creator can modify in addition to the user's read abilities, a user can be creator of a data item +2. **moderator** - a creator can define moderators for a data item. Moderators can change a data item as a creator can. +3. **contributor** (Component) - is a contributor to a component, project, similar (but not the same) to a moderator. In addition to moderator, this role has been added to identify contributors (or that contributors get the fame). +In contrast, the contributor cannot delete data items. +5. **project responsible** (Project) - is a contributor, just named differently to identify the responsible person. +6. **lead architect** (Project) - is a contributor, just named differently to identify the responsible person. an architect refers to the person who has that role of the project or product. This role has been added to identify architects to have a contact person for technical questions. +7. **contact** (Release) - deprecated, should be renamed to contributor see #100. + +`group (department)`, `contributor`, `moderator` and `owner` roles are entity specific, `user`, `clearing admin` and `admin` are roles assigned to a user. + +### Additional Project Visibility + +In addition to the roles mentioned above, each project has a separate visibility setting (technically an attribute of the project document). There are four project visibility levels: + +1. Private - no one but the creator can read. +2. Me and moderators - involves all moderators and contributors, basically all names that are named among the attributes (lead architect, project responsible, contributors) +3. Department / business unit (should be renamed) - refer to the group the users are in. +4. Public - all registered users of the liferay / sw360 application (login required). + +The access rules are implemented in`lib-datahandler`. In the package, `com.siemens.sw360.datahandler.permissions` this is implemented in `ProjectPermissions`. See methods `isVisible` and `userIsEquivalentToModeratorinProject()` for the actual rules. + +### Overall Access Matrix + +The following table presents the SW360 Role-Authorisation-Model. + +The row specifies which action to take, the column the role of the actor. Cell entries specify which entity type can be acted upon. + +| | creator | moderator | contributor | user | clearing admin | (sw360)admin | +| --- | ----------- | --------- | ----- | ---- | -------- | ----- | +| create | - | - | - | PCRV | PCRVL | PCRVL | +| read | P | P | P | (P²)CRVL | (P²)CRVL | PCRVL | +| edit | PCR | PCR | PCR | (all created ones) | PCRVL | PCRVL | +| delete | PCR | PCR | - | (all created ones) | L | PCRVL | + +P² : only if the user is member of the group of the project (or has created the project) + +Note that ECC Admins and Security Admins have only the ability to write ECC and security data respectively at given records. However, as for the other access rights this role does not enhance anything above users. + +#### Legend + +| acronym | description | +| ------- | ----------- | +| P | project | +| C | component| +| R | release | +| V | vendor | +| L | license | + +## Technical Info + +The role access rules are put into `lib-datahandler`. In the package, `com.siemens.sw360.datahandler.permissions` there are implementing classes of a template class `DocumentPermissions`. As an example, `ProjectPermissions` extends abstract class `DocumentPermissions`. + +At run time, a permissions object consisting of a document and a user is created: In `PermissionUtils` (same package) there is a static method `makePermissions