Skip to content

Test 46663: Inline Error for Empty Question Delete#11453

Open
matheuszych wants to merge 2 commits into
ILIAS-eLearning:release_11from
matheuszych:ta/46663
Open

Test 46663: Inline Error for Empty Question Delete#11453
matheuszych wants to merge 2 commits into
ILIAS-eLearning:release_11from
matheuszych:ta/46663

Conversation

@matheuszych
Copy link
Copy Markdown
Contributor

https://mantis.ilias.de/view.php?id=46663

Aims to add no questions selected error message directly to question deletion modal.
@thojou

@matheuszych matheuszych changed the title T&A 46663: Adds no questions selected error message directly to question deletion modal Test 46663: Inline Error for Empty Question Delete May 4, 2026
@dsstrassner
Copy link
Copy Markdown
Contributor

@kergomard please review!

@dsstrassner dsstrassner added bugfix php Pull requests that update Php code labels May 13, 2026
Copy link
Copy Markdown
Contributor

@kergomard kergomard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @matheuszych

Thank you very much for the PR. I do not think we should change anything in the UI-Components to achieve these fixes, so please remove the changes there. You can actually keep most of what you have, as far as I can see. If you feel strongly about the changes in the UI-Component, you would have to provide them separately.
Please remove the return false; on line 223 of QuestionTableActions. We never get there and if we do, things are very, very, wrong and we should notice.

Thanks again and best,
@kergomard

@matheuszych
Copy link
Copy Markdown
Contributor Author

Hello @kergomard ,

Thank you for your feedback!

If we remove the return false; here and something goes wrong, execution could continue. Because it wouldn’t be interrupted by a return, break, or exit, it might proceed to the next case, ACTION_DELETE_CONFIRMED. Since we wouldn’t have a modal at that point, the first if condition would most likely prevent further unintended execution. Nonetheless, I would propose keeping the return false; to definitively prevent that scenario and to keep the overall control flow clear and correct. There are many other places where we, for example, call $this->ctrl->redirect($this, '....'); followed by a return with a placeholder value purely for structural and syntax reasons.

image

What we could or should do is prepend the return false; with a log entry.

I tested everything without the UI changes, and it does not work without them. You get a valid response, but the modal does not open. To make it work, the HTML structure needs to match that of tpl.datatable.html (which was probably the original intention). If you want, I can split this PR into two, but the UI changes are definitely necessary.

Best regards
@matheuszych

@kergomard
Copy link
Copy Markdown
Contributor

Hi @matheuszych

Thank you for the explanation. I'm fine with keeping the return false;.

I added a (temporary) fix for this issue that I already had handy with 73617e8 .

If you want to go with a more proper fix (ie. that the correct modal-type is shown), please split the UI changes out, probably with it's own Mantis-Issue and a good explanation for the UI coordinators, and update the description of this PR so that it becomes clear, that we need to merge this as soon as the other one is merged. You will also need to revert my current fix.

Thank you very much,
@kergomard

See: https://mantis.ilias.de/view.php?id=46663

`QuestionsTableActions` now receives `ResponseHandler`: the delete action renders the async payload through it and returns instead of calling `exit()`. `getDeleteConfirmation()` returns a failure `MessageBox` with `msg_no_questions_selected` when no question rows are selected, otherwise the interruptive modal. The ordering-table async-message area in `tpl.orderingtable.html` uses a native `<dialog>` and a `formmethod="dialog"` close control so that message payload displays correctly; `OrderingRendererTest` expectations were updated.
@matheuszych
Copy link
Copy Markdown
Contributor Author

Hello @kergomard ,

I moved the UI changes to a separate PR and also added the commit reversion here.

This PR depends on #11577.

Best regards
@matheuszych

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix php Pull requests that update Php code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants