added version 1.0 doc

.github/workflows/python-app.yml

@@ -22,7 +22,8 @@ jobs:
       - run: |
             pip install mkdocs-material
             pip install mike
+            pip install mkdocs-glightbox
             git config --global user.email "action@github.com"
             git config --global user.name 'Actions'
 
-      - run: mike deploy --push --update-aliases 0.1 latest
+      - run: mike deploy --push --update-aliases 1.0 latest

docs/API.md

@@ -0,0 +1,4 @@
+- [Postman APIs](https://www.postman.com/aptrs-api/aptrs-workspace/api/7714b268-664f-4300-b389-f6ec34829350/definition/b12bbcd0-6a19-4b80-bc1e-0315d2730c80?version=62baf360-29f0-466f-9579-ffdae037a890&view=documentation)
+- [Postman API Collection](https://www.postman.com/aptrs-api/aptrs-workspace/collection/gly1r21/aptrs)
+- [Swagger](https://api.aptrs.com)
+

docs/Features/Users/users.md

@@ -0,0 +1,33 @@
+# User Management in APTRS
+
+APTRS provides robust user management capabilities, allowing you to add, edit, and delete users. Each user can log in to the APTRS platform using their credentials, and they have the option to set a profile photo through the Edit Profile feature. In version 1.0, users are also able to change their passwords.
+
+
+![User Page](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/user.png)
+
+### User Types
+There are two types of users in APTRS:
+
+1. Admin Users: Admin users have elevated permissions and can perform administrative tasks, including managing user accounts and configurations.
+2. Non-Admin Users: Non-admin users have restricted access and can perform tasks based on the permissions and groups assigned to them.
+
+
+All users can log in and perform tasks according to their assigned permissions and groups. 
+
+
+!!! info 
+
+    For detailed information on permissions and groups, please refer to the Permissions and Groups section.
+
+
+### User Classification
+Users are classified into two categories:
+
+1. Internal Users (Staff Users): By default, all users added to the system are marked as staff users, indicating they are internal users of the APTRS.
+2. External Users (Non-Staff Users): External users are designated as non-staff users. For details on managing non-staff users, please refer to the Customer section.
+
+This structured approach to user management ensures that you can effectively manage access levels and user capabilities within the APTRS platform.
+
+
+### Important Note on Deleting Users
+All projects in APTRS must have an owner. Deleting a user will cause errors, as projects assigned to that user will no longer have an owner. If you need to disable a user’s account, it is recommended to set the account to "inactive" rather than deleting it. If you choose to delete the user, be aware that you will need to manually reassign ownership of all the projects associated with that user to avoid issues.

docs/Features/company/company.md

@@ -0,0 +1,33 @@
+# Company Management in APTRS
+
+APTRS allows you to add and manage companies, with two types of companies supported: Internal Companies and External (Non-Internal) Companies.
+
+![Comapany Page](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/company.png)
+
+
+## Internal Companies
+APTRS assumes that your company, the one deploying and using APTRS, is the internal company. When you deploy APTRS for the first time, an internal company is automatically created. This company is assigned to you and cannot be deleted or replaced. However, you can rename it to reflect your actual company name.
+
+Key details about internal companies:
+
+- **Internal Company Setup**: The internal company is auto-created during the initial setup, and no additional internal companies can be added afterward.
+- **User Assignment**: All users added through the User Management page will automatically be part of the internal company.
+- **Reports**: Users and data from the internal company will be reflected in your reports as staff or internal users.
+
+
+## External (Non-Internal) Companies
+All companies manually added after the initial setup are classified as External Companies. These are typically client companies or third-party organizations.
+
+Key details about external companies:
+
+- **User Management**: You cannot add users to external companies through the User Management page. Any user added through this page will be assigned as a staff member of the internal company.
+- **Assigning Users to External Companies**: To assign users to external companies, you need to go through the Customer section, which manages external users.
+- **Projects**: You can create projects for both internal and external companies, allowing you to track and manage work for client companies separately from your own.
+
+This setup ensures a clear distinction between your internal users and external client companies, making it easier to manage access, projects, and reports within APTRS.
+
+
+!!! warning
+
+    Deleting a company will also delete all associated users. Make sure to reassign or handle any users before deleting a company.
+

docs/Features/company/customer.md

@@ -0,0 +1,20 @@
+# Customer Management in APTRS
+
+
+Customers in APTRS are external users who belong to external (non-internal) companies. You can manage these users from the Customer page, where external users are added and tracked, and they are included in reports as customer users.
+
+
+![Comapany Page](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/customer.png)
+
+
+### Adding Customers
+When adding a customer, you will need to provide the following information:
+
+- Email: The customer's email address.
+- Company: The external company they belong to.
+- Password: A password is required as part of the future functionality.
+
+
+Though passwords are required during customer creation, as of version 1.0, external users do not yet have access to login, API, or dashboard features. These features are planned for future releases, where customers will be able to log into the APTRS dashboard, view ongoing and past projects, download reports, and more.
+
+This allows APTRS to lay the groundwork for future functionality while managing customer data and ensuring they are accurately represented in reports.

docs/Features/configuration/configuration.md

@@ -0,0 +1,7 @@
+# Configuration
+
+The Configuration section allows admin users or users with the Manage Configurations permission to add and manage various settings. In APTRS, users can define Project Types, such as "Mobile Application Testing," which are used when creating projects and are also referenced in PDF and DOCX reports. Multiple project types can be added to suit different testing needs.
+
+In addition to project types, users can also create Report Standards. When generating a report, users are required to select the applicable testing standard, such as OWASP for web application testing. Users can add additional standards here, which can then be used in the generated reports.
+
+![Configuration Page](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/config.png)

docs/Features/dashboard/dashboard.md

@@ -0,0 +1,10 @@
+# Dashboard
+
+
+The Dashboard provides a personalized view of projects based on the logged-in user’s ownership and project status. Unlike the Projects View Page, which lists all projects within APTRS, the Dashboard only displays projects where the logged-in user is the owner and the project is not marked as completed. The Dashboard shows projects with the following statuses: Delay, In Progress, or Upcoming, as long as the user is the owner of those projects.
+
+In addition to active or upcoming projects, the Dashboard also displays completed projects if the project has an active retest. Even if a project is marked as completed, it will be shown in the Dashboard if it has any upcoming, in-progress, or delayed retests where the logged-in user is the owner of the retest task.
+
+This also applies in cases where the user is the owner of the retest task for a completed project, even if the user is not the owner of the original project. In such cases, the project will still appear on the Dashboard, allowing the user to view and manage their active retest tasks.
+
+![Dashboard Page](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/dashboard.png)

docs/Features/index.md

@@ -0,0 +1,2 @@
+APTRS offers various features and configurations, including the management of companies, customers, projects, retests, different types of reports, configurations, templates, and more. The Features Documentation provides detailed information on the different setups, features, and use cases.
+

docs/Features/permission/permission.md

@@ -0,0 +1,42 @@
+
+# Groups and Permissions in APTRS
+
+APTRS uses permissions to control access to certain APIs and restrict features to specific users. To streamline this process, APTRS allows you to create groups and assign permissions to those groups. Once a group is created, you can assign users to one or more groups. A user assigned to multiple groups will inherit all the permissions from those groups.
+
+![Group Page](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/group.png)
+
+
+
+### How Permissions Work
+Permissions are pre-defined within APTRS to regulate access to various functionalities. These permissions cannot be modified or created from the user interface, as they are hard-coded in the backend. However, you can create custom groups and assign these predefined permissions to the groups. When users are assigned to a group, they will automatically gain all the permissions associated with that group.
+
+### Admin Users and Permissions
+Admin users in APTRS are not restricted by permissions or group assignments. This means that even if an admin user has no group assigned or is assigned to a group with limited permissions, they will still have full access to all features and APIs in the system. Admin users are always granted full control, regardless of group membership or assigned permissions.
+
+### Default Groups
+When you first deploy APTRS, several default groups are created with specific permissions. The most important groups are Project Manager and Manager. These groups are crucial for report generation, as they are used to add project manager and manager details to reports.
+
+While you can edit the permissions assigned to these groups, it is important to retain the group names ("Project Manager" and "Manager") if you want APTRS to correctly include project manager and manager details in the reports. Removing or renaming these groups may cause issues with report generation and prevent the correct user details from being added to reports.
+
+### List of Permissions (as of version 1.0)
+
+- Manage Users:
+Users with this permission can add, edit, and delete users, manage groups, and assign permissions to groups. They can also create and delete groups.
+
+- Manage Projects:
+Users with this permission can create, edit, and delete projects. They can add vulnerabilities or retests within a project, generate reports, and add scope to projects. By default, users cannot select project or retest owners; projects and retests created by users with this permission will automatically mark the creator as the owner.
+
+- Assign Projects:
+This permission allows users to select and assign project or retest owners. Users with this permission can assign any user as the owner of a project or retest.
+
+- Manage Vulnerability Data:
+Users with this permission can add, edit, and delete entries in the vulnerability database or templates.
+
+- Manage Customers:
+Users with this permission can add, edit, and delete customers.
+
+- Manage Companies:
+Users with this permission can add, edit, and delete companies.
+
+- Manage Configurations:
+Users with this permission can manage various application configurations.

docs/Features/project/Vulnerability.md

@@ -0,0 +1,89 @@
+Each project can have associated vulnerabilities. You can navigate to the Vulnerability tab within a project to manage its vulnerabilities. This tab allows you to add, edit, or remove vulnerabilities specific to that project, providing a dedicated space to document identified security issues, their descriptions, solutions, CVSS scores, and other relevant details.
+
+Using the Vulnerability Database, you can quickly import common vulnerabilities with pre-filled information, saving time when adding recurring or well-documented issues across multiple projects.
+
+
+![Project Vulnerability](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/project-vulnerability.png)
+
+
+### Adding Vulnerabilities
+
+APTRS provides multiple ways to add vulnerabilities to a project, offering flexibility in how you manage and document security issues.
+
+
+- **Search and Add**: This feature allows you to search for vulnerabilities by title or name from the Vulnerability DB or Template. Once you select a vulnerability from the search results, a new entry is created within the project, automatically populated with the title, description, solution, reference link, and CVSS score from the Vulnerability DB. This approach allows for efficient reuse of information with pre-filled details, saving time on repetitive entries.
+
+- **Add New**: Selecting "Add New" will create a blank vulnerability entry within the project. All fields are initially empty except for the title, which is set to "New Vulnerability." This option is ideal if you need to manually document unique vulnerabilities not in the database. You can fill in all required details such as description, solution, and severity.
+
+- **Upload CSV**: This option is designed specifically for importing vulnerabilities from Nessus scan outputs. You can upload a Nessus vulnerability scan CSV report, which APTRS will parse to extract details such as URL or IP, port, title, description, and more. Parsed vulnerabilities are then added directly to the project, saving time on data entry for larger assessments.
+
+### Nessus CSV
+
+This feature can also be used for other, non-Nessus scan reports. As long as the CSV file contains the required columns with matching names, APTRS will process it just like a Nessus report, making it a versatile option for importing vulnerabilities from various sources.
+
+
+#### Required CSV Columns
+To ensure that vulnerabilities are parsed correctly, your CSV file should include the following columns:
+
+- Host: The IP address or URL of the affected system.
+- Port: The network port where the vulnerability was found.
+- Name: The title of the vulnerability, providing a brief identifier.
+- Description: A detailed explanation of the vulnerability, including its nature and potential impact.
+- Solution: Recommended actions or patches to mitigate or resolve the vulnerability.
+- Risk: The severity level of the vulnerability (e.g., Info, Low, Medium, High, Critical). APTRS uses this to assign a default CVSS score and vector.
+
+
+#### CVSS Score and Vector
+
+
+As of version 1.0, APTRS does not accept CVSS scores and vectors from CSV imports because default Nessus reports do not include them. Instead, APTRS assigns a default CVSS score and vector based on the **Risk** level provided in the CSV file.
+
+#### Default CVSS Scores and Vectors (CVSS 3.1)
+
+These default values are automatically assigned based on the risk level when the CSV is parsed:
+
+
+
+| Severity      | Base Score                          | Vector               |
+| ----------- | ------------------------------------ |---------------------- |
+| `Critical`       | 9.8  | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
+| `High`       | 7.6 | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L |
+| `Medium`    | 5.5 |   CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L |
+| `Low`    | 3.5 | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N |
+| `Informational`    | 0.0 | CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:N | 
+
+
+These defaults ensure consistency in reporting for imported vulnerabilities, even if specific CVSS details aren’t included in the CSV file.
+
+
+### Vulnerability Instances
+
+Each vulnerability in a project is required to have an **instance**. An instance represents the specific URL, parameter, IP address, and port number of the affected vulnerability. Each instance within a vulnerability can have its own status, allowing for more granular tracking and resolution.
+
+
+
+
+![Vulnerability](https://raw.githubusercontent.com/APTRS/APTRS-Changelog/refs/heads/main/images/vulnerability-instance.png)
+
+
+### Vulnerability and Instance Status
+
+The status of each vulnerability and its instances is tracked individually to provide clear insights into the resolution progress. Below are the details on how the status is managed and calculated for both vulnerabilities and their instances.
+
+The status of a vulnerability and its instances are interconnected. There are three possible statuses for both vulnerabilities and instances:
+
+- **Vulnerable**: The vulnerability or instance has unresolved security issues.
+- **Confirmed Fix**: The vulnerability or instance has been resolved and no longer has security issues.
+- **Accepted Risk**: The vulnerability or instance remains unresolved, but the customer or client has accepted the associated risk.
+
+These statuses function as follows:
+
+1. **Changing Vulnerability Status**: If you change the status of a vulnerability, all instances associated with that vulnerability will automatically be set to the same status. For example, setting a vulnerability to **Accepted Risk** will update all instances within that vulnerability to **Accepted Risk** as well.
+
+2. **Changing Instance Status**: When modifying the status of individual instances within a vulnerability, the overall vulnerability status is recalculated based on its instances' statuses. The rules are as follows:
+
+      - **Confirmed Fix**: For a vulnerability to be marked as Confirmed Fix, all instances must be set to Confirmed Fix. Even a single instance with a different status prevents the vulnerability from being marked as Confirmed Fix.
+      - **Vulnerable**: If any instance is marked as Vulnerable, the entire vulnerability is marked as Vulnerable, regardless of other instances’ statuses.
+      - **Accepted Risk**: If all instances are marked as Accepted Risk, the vulnerability status will also be set to Accepted Risk.
+
+   In short, for a vulnerability to be considered Confirmed Fix, all instances must be Confirmed Fix. To be marked as Accepted Risk, all instances must have that status. Any instance marked as Vulnerable will cause the vulnerability itself to be marked as Vulnerable.