Environment

• MultiPortal Version: 1.2.1
• Proxmox VE Version: 9.2.6
• Deployment Type: HA Cluster

Description
When we create a virtual datacenter via the API, the “reseller” and “tenant” variables in the Proxmox resource pool do not appear to be populated. However, when a datacenter is created via the GUI, the reseller and tenant names do appear there.

Datacenter Name (GUI): Reseller_XYZ.Kunde_ABC.vdc.9672ec9c-4199-43b0-b258-f2ce4135673c

Datacenter Name (API): reseller.tenant.vdc.bbfa10c2-7c52-4d6e-986f-d6c0c156fd80

I also checked the swagger documentation but couldn’t find a way to change this behavior.

Expected Behavior
The ressource pool on Promox includes the reseller and tenant names also when created via api.

Actual Behavior
The ressource pool on Proxmox only includes the id of the virtual datacenter, and doesn’t include the showname of the reseller and tenant when created via api.

Environment

• MultiPortal Version: 1.2.1
• Proxmox VE Version: 9.2.6
• Deployment Type: HA Cluster

Description
We have only 1 specific CPU Model enabled at datacenter level. While we add new nodes to our cluster, then the new host have enabled 71 CPU Models on the database. On the WebUI there are likely random things enabled / disabled while we flip through the sites.

Steps to Reproduce (if applicable)

1. Disable all CPU Models and enable some / one CPU Model(s).
2. Add new nodes to the cluster.
3. Some CPU Models you previously disabled becomes randomly enabled.

Expected Behavior
New nodes in the cluster get the CPU Models from the existing Nodes.

Actual Behavior
New nodes become 71 default enabled CPU Models

Environment

• MultiPortal Version: 1.2.1
• Proxmox VE Version: 9.2.6
• Deployment Type: HA Cluster

Description
We are integrating MultiPortal with an existing ITSM system using the OAuth 2.0 client credentials flow.

The ITSM system sends token requests with the content type:

application/x-www-form-urlencoded

However, the MultiPortal endpoint /access/get-token currently only accepts:

multipart/form-data

This content-type mismatch prevents the ITSM system from completing the OAuth authentication flow.

Expected Behavior
The endpoint /access/get-token should accept valid OAuth 2.0 token requests encoded as application/x-www-form-urlencoded, including client credentials sent in the request body.

Support for the existing multipart/form-data format should remain available for backward compatibility.

Actual Behavior
The endpoint /access/get-token only accepts requests encoded as multipart/form-data.

Requests sent with application/x-www-form-urlencoded are rejected, preventing the ITSM system from completing the OAuth 2.0 client credentials flow.