diff --git a/config.toml b/config.toml
index 1e979d1..cc1834f 100644
--- a/config.toml
+++ b/config.toml
@@ -5,7 +5,6 @@ theme = ["docsy"]
# Language settings
contentDir = "content/en"
defaultContentLanguage = "en"
-defaultContentLanguageInSubdir = false
# Useful when translating.
enableMissingTranslationPlaceholders = true
@@ -14,7 +13,7 @@ enableRobotsTXT = true
# Will give values to .Lastmod etc.
enableGitInfo = true
-disableKinds = ["taxonomy", "taxonomyTerm"]
+disableKinds = ["taxonomy"]
# Highlighting config
pygmentsCodeFences = true
@@ -28,14 +27,33 @@ resampleFilter = "CatmullRom"
quality = 75
anchor = "smart"
+defaultContentLanguage = "en"
+defaultContentLanguageInSubdir = true
[languages]
-[languages.en]
-title = "Eclipse SW360"
-description = "Eclipse SW360 official website"
-languageName = "English"
-# Weight used for sorting.
-weight = 1
+ [languages.en]
+ languageName = "English"
+ weight = 1
+ contentDir = "content/en"
+
+ [languages.fr]
+ languageName = "Français"
+ weight = 2
+ contentDir = "content/fr"
+
+ [languages.ja]
+ languageName = "日本語"
+ weight = 3
+
+ [languages.vi]
+ languageName = "Tiếng Việt"
+ weight = 4
+
+ [languages.zh]
+ languageName = "中文"
+ weight = 5
+
+
[markup]
[markup.goldmark]
diff --git a/content/en/docs/Deployment/Legacy/Deploy-Natively-11.md b/content/en/docs/Deployment/Legacy/Deploy-Natively-11.md
index 8cf1a56..b7088a0 100644
--- a/content/en/docs/Deployment/Legacy/Deploy-Natively-11.md
+++ b/content/en/docs/Deployment/Legacy/Deploy-Natively-11.md
@@ -8,7 +8,9 @@ description:
## Introduction
-We are covering the update for ubuntu 18.04 LTS here, because that is our main / agreed base system for running sw360. sw360 may run on a varienty of other linux distributions or OSes such as macosx, but in order to avoid problem we agreed on having a reference OS, which are the ubuntu long term releases. The author of this guide also uses macosx and homebrew which also works fairly well.
+We are covering the update for Ubuntu 18.04 LTS here because it is our main and agreed-upon base system for running SW360. While SW360 may run on a variety of other Linux distributions or operating systems such as macOS, we have agreed to use Ubuntu Long-Term Releases as a reference OS to avoid compatibility issues. The author of this guide also uses macOS with Homebrew, which works fairly well.
+
+
Please note that during the time, the dependencies are updated and the version info might change.
diff --git a/content/fr/_index.html b/content/fr/_index.html
new file mode 100644
index 0000000..9bd29d2
--- /dev/null
+++ b/content/fr/_index.html
@@ -0,0 +1,69 @@
++++
+title = "SW360"
+linkTitle = "Eclipse SW360"
++++
+
+{{
+ 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.
+
+ {{< figure src="/sw360/img/logos/logo_full.svg" width="400">}}
+
+$ 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