Galette

@Guillaume AGNIERAY could you please take an eye on this one?

1. 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
2. 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).

• 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) ?

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.

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?

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...

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.

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 :)