Anomalie #1695
closedMass adding contribution UI issue on further try
Added by Johan Cwiklinski about 1 year ago. Updated about 1 year ago.
100%
Description
When we open fist time the popup to mass-add a contribution, everything is OK.
Next time, there are several issues (really hard to describe all that happens, but it's easilly reproducible).
Updated by Johan Cwiklinski about 1 year ago
@Guillaume AGNIERAY could you please take an eye on this one?
Updated by Guillaume AGNIERAY about 1 year ago
- closing a modal after filling it's form (when choosing the type of contribution, or when filling details) without using the "cancel" button changes the modals' width on further tries
- same thing as above when an error is thrown after submitting the form
I also noticed that even if all the required fields are filled manually, only one membership contribution is created ; the others selected fail because of missing required dates (that's not the case with donations which seem to be working well).
Questions :- shouldn't the date and period fields be filled automatically like when adding a single contribution ?
- shouldn't the form be reseted when closing the modal at the first time (with or without using the cancel button) ?
Updated by Johan Cwiklinski about 1 year ago
Guillaume AGNIERAY a écrit (#note-2):
I also noticed that even if all the required fields are filled manually, only one membership contribution is created ; the others selected fail because of missing required dates (that's not the case with donations which seem to be working well).
Oh :/ I did not see that yet; I was focused on trying to find/solve the original issue (by creating one contribution :D).
I'll keep that in mind when I'll have time to work again on the issue.
Questions :
- shouldn't the date and period fields be filled automatically like when adding a single contribution ?
That's a good question, I was asking the same. On the draft PR I've made yesterday, I've filled the duration from preferences like on regular contribution add; so I guess having dates preset aswell would not be a bad thing.
- shouldn't the form be reseted when closing the modal at the first time (with or without using the cancel button) ?
Yes, I think so. There is no need to keep the form if modal has been closed, from any way.
Updated by Johan Cwiklinski about 1 year ago
I've fixed #1694; solution was "just" to setup properly the contribution like on regular add. This way, fields are now prefilled, and required fields set properly.
Missing date or extension was already a cause of application error in 0.9.x. (I've setup a 0.9.x demo on https://demo.master.galette.eu).
Appart of the display issues on mass contribution add modal; several other issues appears:
- form can be sent even if required fields are not set
- errors are not shown on the UI, the only way to see them is to look in logs
On 0.9.x (see https://demo.master.galette.eu); only the contribution type selection dropdown was shown as a modal; then user was then redirected to "regular" contribution page add.
Replacing modal usage with standard page may fix all issues at once. What's your opinion?
Updated by Guillaume AGNIERAY about 1 year ago
Johan Cwiklinski a écrit (#note-4):
I've fixed #1694; solution was "just" to setup properly the contribution like on regular add. This way, fields are now prefilled, and required fields set properly.
Missing date or extension was already a cause of application error in 0.9.x. (I've setup a 0.9.x demo on https://demo.master.galette.eu).
After testing I confirm the fix is working.
Appart of the display issues on mass contribution add modal; several other issues appears:
- form can be sent even if required fields are not set
Indeed :(
It seems that the browser validation with HTML is not working in modals.
I presume that it must be done with JS in such cases : https://fomantic-ui.com/behaviors/form.html
Display issues could be solved changing some modal's settings, and reseting the modal content when an error is thrown by the server.
- errors are not shown on the UI, the only way to see them is to look in logs
Yes.
Testing on 0.9.x, there is no error from the server shown in the UI when forcing the same error as on 1.0.0 to occure, neither.
In this case, a Slim error is displayed on screen.
I get the same error on 1.0.0 in the jqXHR object :
405 Method Not Allowed The application could not run because of the following error: Details Type : Slim\Exception\HttpMethodNotAllowedException Code : 405 Message : Method not allowed. Must be one of: POST File : /var/html/galette/galette/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php Line : 79 Trace #0 /var/html/galette/galette/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php(44): Slim\Middleware\RoutingMiddleware->performRouting() #1 /var/html/galette/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(121): Slim\Middleware\RoutingMiddleware->process() #2 /var/html/galette/galette/vendor/slim/slim/Slim/Middleware/ErrorMiddleware.php(76): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #3 /var/html/galette/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(121): Slim\Middleware\ErrorMiddleware->process() #4 /var/html/galette/galette/vendor/slim/twig-view/src/TwigMiddleware.php(115): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #5 /var/html/galette/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(121): Slim\Views\TwigMiddleware->process() #6 /var/html/galette/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(65): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #7 /var/html/galette/galette/vendor/slim/slim/Slim/App.php(199): Slim\MiddlewareDispatcher->handle() #8 /var/html/galette/galette/vendor/slim/slim/Slim/App.php(183): Slim\App->handle() #9 /var/html/galette/galette/includes/main.inc.php(244): Slim\App->run() #10 /var/html/galette/galette/webroot/index.php(57): require_once('...') #11 {main}
On 0.9.x (see https://demo.master.galette.eu); only the contribution type selection dropdown was shown as a modal; then user was then redirected to "regular" contribution page add.
Replacing modal usage with standard page may fix all issues at once. What's your opinion?
Yes.
After all, it's a question of UX.
Which is the best actually ?
A full Ajax experience on this process, without pages loads, in multiple modals? Or the previous one ?
I introduced multiple modals in the UX because I tought it was better.
But it might not be very maintainable and might require too much more JS code in the end...
Updated by Guillaume AGNIERAY about 1 year ago
I don't know if other forms in modals suffer from the same client side validation issues with required fields, but at least for this case, I made a PR that, I think, properly fixes the display issues without changing the process through modals.
So if this solution suits you, it might hopefully be reproducted or factorized for other similar use cases.
FUI now provides a way to make use of the native browser built-in form validation that helps to fix the missing client side validation messages on required fields in modals.
The other display issues were fixed by removing the modal from DOM when it is hidden, when the form is valid and submitted, or when an error is thrown.
Updated by Guillaume AGNIERAY about 1 year ago
- Assignee set to Guillaume AGNIERAY
Updated by Guillaume AGNIERAY about 1 year ago
- Status changed from Nouveau to In Progress
Updated by Johan Cwiklinski about 1 year ago
Guillaume AGNIERAY a écrit (#note-5):
[...]
But it might not be very maintainable and might require too much more JS code in the end...
I have no preferences, but I also had in mind it may be difficult to maintain.
Guillaume AGNIERAY a écrit (#note-6):
I don't know if other forms in modals suffer from the same client side validation issues with required fields, but at least for this case, I made a PR that, I think, properly fixes the display issues without changing the process through modals.
So if this solution suits you, it might hopefully be reproducted or factorized for other similar use cases.
FUI now provides a way to make use of the native browser built-in form validation that helps to fix the missing client side validation messages on required fields in modals.
Oh yes, that's perfect! It required way less code that I supposed necessary; this sounds very good.
The other display issues were fixed by removing the modal from DOM when it is hidden, when the form is valid and submitted, or when an error is thrown.
OK, great!
Thank you very much for your fixes :)
Updated by Guillaume AGNIERAY about 1 year ago
- Status changed from In Progress to Résolu
- % Done changed from 0 to 100
Appliqué par commit fb561fe3b2c49363a8bf8cf1580b1ab6ee39b4ae.
Updated by Johan Cwiklinski about 1 year ago
- Status changed from Résolu to Fermé