-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Plugin version: 3.2.6
GLPI version: 11.x
Severity: Critical
File: src/HolidayValidation.php lines 522–530
Related issue: #27
Description
The approve and refuse buttons on the holiday validation form are rendered as <i> icons with jQuery click handlers. When clicked, the JS handler attempts to inject hidden inputs into a form selected by the hardcoded ID #formvalidation and then submit it:
// Current code — HolidayValidation.php ~line 522
$('#accept_holiday').click(function() {
$('#formvalidation').append("<input type='hidden' name='accept_holiday' value='1' />");
$('#formvalidation').append("<input type='hidden' name='update' value='1' />");
$('#formvalidation').submit();
});
$('#refuse_holiday').click(function() {
$('#formvalidation').append("<input type='hidden' name='refuse_holiday' value='1' />");
$('#formvalidation').append("<input type='hidden' name='update' value='1' />");
$('#formvalidation').submit();
});In GLPI 11 the form does not have a static id="formvalidation" — the form ID is generated dynamically. The selector $('#formvalidation') returns an empty jQuery object, so .append() and .submit() are no-ops. The page appears to do nothing when the buttons are clicked.
Steps to reproduce
- Log in as a user with
plugin_activity_can_validateright. - Open a holiday validation form that is in "Waiting" status.
- Click the green checkmark (Accept) or red X (Refuse) icon.
- Observe: the page does not submit, no status change occurs.
Expected behavior
Clicking Accept or Refuse should submit the form with the appropriate hidden field, triggering the status update.
Proposed fix
Traverse the DOM from the clicked element up to its parent <form> instead of relying on a hardcoded ID:
// HolidayValidation.php — replace the scriptBlock content
echo Html::scriptBlock('
$("#accept_holiday").on("click", function () {
var $form = $(this).closest("form");
$form.append("<input type=\"hidden\" name=\"accept_holiday\" value=\"1\">");
$form.append("<input type=\"hidden\" name=\"update\" value=\"1\">");
$form.trigger("submit");
});
$("#refuse_holiday").on("click", function () {
var $form = $(this).closest("form");
$form.append("<input type=\"hidden\" name=\"refuse_holiday\" value=\"1\">");
$form.append("<input type=\"hidden\" name=\"update\" value=\"1\">");
$form.trigger("submit");
});
');Or alternatively, replace the <i> icon approach with proper <button type="submit"> elements inside the form, which is the standard GLPI 11 pattern and requires no JavaScript at all:
// Accept button
echo Html::submit(__('Accept holiday', 'activity'), [
'name' => 'accept_holiday',
'value' => 1,
'class' => 'btn btn-success',
'icon' => 'ti ti-circle-check',
]);
// Refuse button
echo Html::submit(__('Refuse holiday', 'activity'), [
'name' => 'refuse_holiday',
'value' => 1,
'class' => 'btn btn-danger',
'icon' => 'ti ti-circle-x',
]);Using native submit buttons eliminates the JavaScript dependency entirely and is fully GLPI 11 compliant.
Additional context
- This issue was first reported in Can't approve/refuse holiday (button without reaction) #27 against GLPI 10. The root cause (hardcoded form ID) has not been fixed in v3.2.6.
- The same pattern (injecting into
#formvalidation) was used in GLPI 9/10 where the form had that ID by convention. GLPI 11 changed the form rendering.