Fix product.html column sizing with autoWidth: false. Same as here https://github.com/DefectDojo/django-DefectDojo/pull/13835

docs/content/en/about_defectdojo/pro_features.md

@@ -18,6 +18,12 @@ See our [Pro UI Guide](../ui_pro_vs_os) for more information.
 
 ![image](images/enabling_deduplication_within_an_engagement_2.png)
 
+### Assets/Organizations
+
+DefectDojo Pro allows for improved organizational visualization for large lists of repositories or other business structures.  See [Assets/Organizations documentation](/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations/) for details.
+
+![image](images/asset_hierarchy_diagram.png)
+
 ### Finding Priority
 
 DefectDojo Pro can pre-triage your Findings by Priority and Risk, allowing your team to identify and fix your most critical issues first.

docs/content/en/changelog/changelog.md

@@ -8,8 +8,57 @@ Here are the release notes for **DefectDojo Pro (Cloud Version)**. These release
 
 For Open Source release notes, please see the [Releases page on GitHub](https://github.com/DefectDojo/django-DefectDojo/releases), or alternatively consult the Open Source [upgrade notes](/en/open_source/upgrading/upgrading_guide/).
 
+## Dec 2025: v2.53
+
+### Dec 8, 2025: v2.53.1
+
+* **(Assets/Organizations)** Introduced overhaul to Products/Product Types, added the ability to create and diagram relationships between Assets.  See [Assets/Organizations documentation](/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations/) for details, and information on opting in to the Beta.
+* **(Findings)** Added new KEV fields for ransomware, exploits, and date handling.
+
+### Dec 1, 2025: v2.53.0
+
+* **(Pro UI)** Added Asset Hierarchy.
+* **(Priority)** Priority and Risk can now be overridden manually, or through Rules Engine.
+
+## Nov 2025: v2.52
+
+### Nov 24, 2025: v2.52.3
+
+* **(Pro UI)** Improved error messaging for failed Imports.
+* **(Pro UI)** Added Engagement Tags column to Finding lists
+
+
+### Nov 17, 2025: v2.52.2
+
+* No significant feature changes.
+
+### Nov 10, 2025: v2.52.1
+
+* **(Pro UI)** Finding view now shows all associated Endpoints, not just Active Endpoints
+
+
+### Nov 3, 2025: v2.52.0
+
+* **(Pro UI)** In-app Contact Support form now requires a valid email address in your user profile.
+* **(Pro UI)** You can now Add Files to Findings through the Pro UI directly from Finding Lists.
+* **(Pro UI)** Unicode letters are now allowed in Tags.
+
 ## Oct 2025: v2.51
 
+### Oct 27, 2025: v2.51.3
+
+* **(Tools)** Added Nuclei scan support for Smart Upload.
+* **(Priority)** Added Prioritization Engine to allow for configurable Priority and Risk calculations for individual Findings under a given Product.
+* **(Metrics)** Updated Metrics table to include Products with zero Findings (as a result of filter parameters, or otherwise).
+* **(Pro UI)** Added Surveys to Pro UI.
+
+
+
+### Oct 20, 2025: v2.51.2
+
+* **(Connectors)** Added Anchore Enterprise Connector.
+
+
 ### Oct 14, 2025: v2.51.1
 
 * **(Pro UI)** Added Finding Quick Report feature.  Quick report allows users to quickly render an HTML report with the currently displayed Findings on a Finding table.

docs/content/en/customize_dojo/user_management/configure_sso.md

@@ -133,7 +133,7 @@ The Azure AD token need to be configured to include Group IDs. Without this step
 To update the format of the token, add a [Group Claim](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) that applies to whatever Group type you are using.
 If unsure of what type that is, select `All Groups`. Do not activate `Emit groups as role claims` within the Azure AD "Token configuration" page.
 
-Application API permissions need to be updated with the `Group.Read.All` permission so that groups can be read on behalf of the user that has successfully signed in.
+Application API permissions need to be updated with the `GroupMember.Read.All` or `Group.Read.All` permission so that groups can be read on behalf of the user that has successfully signed in.  `GroupMember.Read.All` is recommended as this grants the application fewer permissions.
 
 ##### Group Cleaning
 
@@ -169,7 +169,7 @@ The Azure AD token returned by Azure will also need to be configured to include
 
 If unsure of what type that is, select `All Groups`. Do not activate `Emit groups as role claims` within the Azure AD "Token configuration" page.
 
-Application API permissions need to be updated with the `Group.Read.All` permission so that groups can be read on behalf of the user that has successfully signed in.
+Application API permissions need to be updated with the `GroupMember.Read.All` or `Group.Read.All` permission so that groups can be read on behalf of the user that has successfully signed in.  `GroupMember.Read.All` is recommended as this grants the application fewer permissions.
 
 To limit the amount of groups imported from Azure AD, a regular expression can be used as the following:
 

docs/content/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations.md

@@ -0,0 +1,123 @@
+---
+title: "⚠️ Assets and Organizations (Pro)"
+description: "DefectDojo Pro - Product Hierarchy Overhaul"
+---
+
+DefectDojo Pro is extending the Product/Product Type object classes to provide greater flexibility with the data model.
+
+Currently, this feature is in Beta. Pro users who are interested in opting in can do so by emailing [support@defectdojo.com](mailto:support@defectdojo.com).
+
+## Significant Changes
+
+* **Product Types** have been renamed to "Organizations", and **Products** have been renamed to "Assets".  Currently, this name change is opt-in for existing DefectDojo Pro subscriptions.
+* **Assets** can now have parent/child relationships with one another to further sub-categorize Organizational components. 
+
+### Organizations
+
+As with Product Types, **Organizations** should be understood as a top-level category.  You can use these to separate your business' core software applications, departments or business functions.
+
+For example, you could create an Organization for many repository groupings: "Core Application", "Infrastructure", "DevOps", "Analytics", "SDK" could all contain multiple code repos.
+
+Keep in mind that for reporting purposes, it’s easier to combine multiple Organizations into a single document than it is to subdivide a single Organization into separate documents. Therefore, we recommend setting up Organizations at as granular a level as makes sense for your team's reports. For example, there is no need to represent a large business division as an Organization if you're primarily going to be reporting on individual departments within that division.
+
+### Assets
+
+Assets are meant to represent subdivisions of your Organizations.  However, unlike Products, Assets can be nested, and have parent-child relationships with one another.
+
+## Asset Nesting Examples
+
+### Asset-Level Branch Representation
+
+Development and feature branches can be represented in a variety of ways; separate Engagements or Tests are existing ways that you can represent the difference between your Production, Dev, and other feature branches.
+
+You can also represent these using nested Assets.  Consider the following Asset tree:
+
+```
+Core Application [Organization]
+└── webapp-frontend
+    ├── webapp-frontend/prod
+    └── webapp-frontend/dev
+        ├── webapp-frontend/dev/feature-a
+        └── webapp-frontend/dev/feature-b
+```
+
+In this environment, each branch (`prod`, `dev`, `feature a`, `feature b`) could have its own Engagements and Tests that are isolated from the other Assets, so that they don't deduplicate against each other.  This setup can also ease in navigation, as Asset names can directly correspond to the path on Git.
+
+### Mono-Repo: Separate Components
+
+If you use a single repository for all of your code, but have different teams contributing to directories within that repository, you can set up your Asset nesting to represent that structure.
+
+```
+Core Application [Organization]
+├── webapp-frontend [Parent Asset]
+│   ├── mobile-ios
+│   ├── mobile-android
+│   └── mobile-sdk
+├── webapp-backend [Parent Asset]
+│   ├── database
+│   └── api
+└── infra [Parent Asset]
+    ├── docker
+    ├── kubernetes
+    └── nginx
+```
+
+In this diagram, every element under "Core Application" could be recorded as a separate Asset, with unique business criticality (see: [Priority & Risk](/en/working_with_findings/priority_adjustments/)), RBAC, and corresponding Engagements and Tests.  You could continue to test, and store results, on the parent Asset (for example, `webapp-backend`), but you could also run isolated testing on a particular child Asset (for example, `database`).
+
+### Pen Tests: Isolated RBAC
+
+If you want to store pen test results within a single asset, but you don't want testers to be able to look at asset data, you could create child assets for each testing group to upload their results.
+
+```
+Core Application [Organization]
+└── webapp-frontend [Parent Asset]
+    ├── Pen Test Group A
+    └── Pen Test Group B
+```
+
+Crucially, giving a user RBAC access to a single Child Asset (e.g. `Pen Test Group A`) here does not allow them to see any Findings from other Child Assets (e.g. `Pen Test Group B`), nor does it allow them to see Findings in the Parent Asset (`webapp-frontend`).
+
+The Parent Asset could contain Engagements representing CI/CD results, internal Testing, historical data, or other Finding data which you do not want 3rd parties to be able to discover.  Creating a Child Asset for specific Test results allows your internal team to report on those results in combination with the state of the parent Asset.
+
+## Visualizing Assets - Hierarchy
+
+You can visualize the structure of Assets in DefectDojo, and change relationships using the Asset Hierarchy option in the menu.
+
+![image](images/asset_hierarchy.png)
+
+Opening Asset Hierarchy will display a table of all of your Assets which can be filtered.  Selecting one or more Assets from this table will render a hierarchy diagram.
+
+![image](images/asset_hierarchy_diagram.png)
+
+### Diagram navigation
+
+The icons at the top left of the hierarchy diagram allow you to zoom in and out.  Clicking and dragging in this diagram allows you to scroll through the diagram.
+
+Each Asset is rendered as a single node in this diagram, which can be moved around for display purposes.
+
+Assets are connected together using labelled paths, which represent the kind of relationship each note has to one another.  Currently, `parent` is the only label supported.
+
+### Exploring Asset nodes
+
+Each Asset node can be interacted with by clicking on the blue buttons.  These buttons appear only when an Asset node is selected (by clicking on the node).
+
+![image](images/asset_hierarchy_node.png)
+
+* 👁️ (eyeball icon) will take you directly to the corresponding Asset View (formerly known as the Product View).
+* ✏️ (pencil icon) will open a modal with the Edit Asset form (formerly known as the Edit Product form)
+* ➕ (plus icon) will allow you to add a new Child Asset to this Asset.  The Asset does not need to be currently visible in the diagram, but must be part of the same Organization.
+* ✥ (four-arrows icon) allows you to change the Parent Asset of the currently selected Asset.
+* 🗑️ (trash can icon) allows you to remove an Asset's parent relationship. This icon only appears if an Asset already has a Parent.
+
+If your diagram displays an Asset with un-selected Parent Assets, you can click the Load More button to populate the diagram with the Parent Asset (as well as that Parent Asset's children).
+
+![image](images/assets_loadmore.png)
+
+## Notes
+
+* Note that deduplication scopes have not changed; Assets only deduplicate Findings within themselves, and do not consider Findings in other Assets, regardless of Parent/Child relationships.
+* RBAC scopes have not changed within this system; each Asset is still considered an individual object for the purposes of assigning permissions.  No new RBAC inheritance has been created.
+  * Giving a user access to an entire Organization will still give that user access to all Assets contained within that Organization (as with Product Types).
+  * Giving a user access to a single Asset does not give that user access to any related Parent or Child Assets, nor access to the Organization.
+* There is no limit to the number of Parent/Child relationships that can be created. Theoretically, you could represent a repository's entire directory structure with separate Assets if you wished.
+* Cyclical relationships are not allowed: Parent Assets cannot be Children of their Child Assets.

dojo/templates/dojo/engagements_all.html

@@ -241,6 +241,7 @@ <h3 class="has-filters">
             {% if enable_table_filtering %}
                 var dojoTable = $('#engagements').DataTable({
                     colReorder: true,
+				    autoWidth: false,
                     columnDefs: [
                         {
                             "orderable": false,

dojo/templates/dojo/product.html

@@ -336,6 +336,7 @@ <h3 class="has-filters">
                       );
                   },
                   colReorder: true,
+				  autoWidth: false,
                   "columns": [
                       { "data": "action", "searchable": false },
                       { "data": "product" },