Pull Request resolves #36544

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

Custom fields assigned to a specific category were incorrectly appearing on the new category form even when they had no relevance to the category being created.

Why this happened:

In FieldsHelper::prepareForm(), the variable $assignedCatids is resolved from $data->catid, $data->fieldscatid, or the form's catid value. For a new category form, none of these are available — a category does not belong to another category via a catid field the way an article does. So $assignedCatids resolves to 0.

When getFields() is then called with $data, the condition that populates filter.assigned_cat_ids:

if ($item && (isset($item->catid) || isset($item->fieldscatid))) {

...is never entered, because neither catid nor fieldscatid is set on $data. This means filter.assigned_cat_ids stays as [] (empty), and the model query returns all fields for the context with no category filtering — including fields that are assigned to specific categories.

There is a guard in the code intended to handle this case:

if (!$assignedCatids && !empty($field->assigned_cat_ids) && $form->getField($field->name)) {
    $form->setFieldAttribute($field->name, 'required', 'false');
}

However, this guard never fires because $field->assigned_cat_ids is not populated on the field object returned by the model — it is a filter parameter, not a field property. So category-specific fields render unconditionally on the new category form, and if any of them are marked as required, the user is blocked from saving a new category unless they fill in a field that is irrelevant to the category being created.

The fix:

In prepareForm(), before the second call to getFields(), explicitly set $data->fieldscatid = 0 when no category context can be determined and neither catid nor fieldscatid is already set on $data:

if (!$assignedCatids && !isset($data->catid) && !isset($data->fieldscatid)) {
    $data->fieldscatid = 0;
}

This causes getFields() to enter the filtering condition and set filter.assigned_cat_ids to [0], which restricts the model query to return only fields with no category assignment — the correct behavior when no category context is known.

Testing Instructions

1. Navigate to Content > Categories and create a new category called "Test category with field". Save & Close.
2. Navigate to Content > Fields, switch the dropdown from Articles to Category.
3. Create a new field called "Test category field", set Required to Yes, and assign it to "Test category with field". Save & Close.
4. Navigate to Content > Categories and click New to create a new category called "Test category without field".
5. Observe the Fields tab on the new category form.

Actual result BEFORE applying this Pull Request

The custom Fields tab loads on the new category form and displays "Test category field" even though it is assigned specifically to "Test category with field". Because the field is marked as required, the new category cannot be saved unless the custom field is filled in, even though it has no relevance to the category being created. Switching the parent category has no effect on the displayed fields until after saving.

Expected result AFTER applying this Pull Request

The new category form loads without the custom field that is assigned to "Test category with field". The Fields tab either does not appear or shows only fields that have no specific category assignment. The new category can be saved without being blocked by irrelevant required fields.

Link to documentations

Please select:

• Documentation link for guide.joomla.org: <link>
• No documentation changes for guide.joomla.org needed
• Pull Request link for manual.joomla.org: <link>
• No documentation changes for manual.joomla.org needed