@jagood Thank you! The default value in the gitlab subscription history table has been removed. I checked again on the behavior of the API in case of an unregistered attribute and commented on the result. Back to you 🏓

@jagood, For the audit/histories table, it makes sense not to use the same restrictions, as its purpose is different. I applied your suggestion! Thank you!

Lukas Wanko (b0df84d3) at 19 Mar 09:17

@jagood Great question! I was trying it out with an extended payload. The "foo" attribute was an additional, unregistered attribute, but your intuition was right. It seems I used a somehow malformed payload back then, and additional attributes are actually just ignored. When I use the following payload, we still receive a success message. TIL 💡

➜  ~ curl --request POST \
  --url "http://gdk.test:8080/api/v4/internal/gitlab_subscriptions/namespaces/22/provision" \
  --header "X-CUSTOMERS-DOT-INTERNAL-TOKEN: XXX"
  --header "Content-Type: application/json" \
  --data '{
    "provision": {
      "base_product": {
        "plan_code": "ultimate",
        "seats": 30,
        "start_date": "2026-03-09",
        "end_date": "2027-03-09",
        "max_seats_used": 10,
        "auto_renew": true,
        "trial": false,
        "foo": "bar"
      },
      "storage": {
        "additional_purchased_storage_size": 100,
        "additional_purchased_storage_ends_on": "2027-03-09"
      },
      "compute_minutes": {
        "extra_shared_runners_minutes_limit": 90
      }
    }
  }'

{"status":"success","message":null,"payload":{"base_product":{"status":"success"},"storage":{"status":"success"},"compute_minutes":{"status":"success"},"add_on_purchases":null}}

With that, the point in time when the merge request at CustomersDot gets deployed does not matter. 🎯

Lukas Wanko (78556c76) at 19 Mar 08:58

ℹ️ Auto-formatting of the GitLab project formats it like this.

Lukas Wanko (e5811f4c) at 18 Mar 15:52

ℹ️ The previous subtitle suggested that the member access configuration is required to access DAP or Duo, although it is primarily used to restrict access rather than allow it. When no rule is configured, access to DAP and Duo works as usual.

@eduardobonet @frwang1 I assume you might want to take a look at this small improvement and I'm happy to receive an approval from you both 🙏

@vjain-gl May I ask you for a frontend review? Thank you!

@lciutacu May I ask you for a Technical Writing review? Thank you!