-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data type not validated in custom form fields #671
Comments
@srutto Theres nowhere near enough if here to debug. Can you clean up this bug report?
See https://developer.mozilla.org/en-US/docs/Bug_writing_guidelines for some more details on how to write a good bug report. |
I think this is about custom form fields. |
@srutto thanks for the update description.. much better! |
* Actually return sane error messages * Push errors directly into $post object * Bind all error to 'custom_field' rather than trying to bind to individual fields as this didn't work and meant no errors were displayed * Still a bit broken since only the last error will get displayed, not great if you have 10 errors and only see 1 * Fix unit test to grab the errors from the $post object
This reverts commit def9e1d.
@aoduor @elle-espere My deployment address is https://indiaoye.crowdmap.com/ Request you to add my report to the above repository. |
@manwinder working on a fix for this. As I had earlier mentioned, this fix will be available once the next version of Ushahidi is released, on April 30th. It will then be made available on crowdmap thereafter. |
* Actually return sane error messages * Push errors directly into $post object * Bind all error to 'custom_field' rather than trying to bind to individual fields as this didn't work and meant no errors were displayed * Still a bit broken since only the last error will get displayed, not great if you have 10 errors and only see 1 * Fix unit test to grab the errors from the $post object
* Actually return sane error messages * Push errors directly into $post object * Bind all error to 'custom_field' rather than trying to bind to individual fields as this didn't work and meant no errors were displayed * Still a bit broken since only the last error will get displayed, not great if you have 10 errors and only see 1 * Fix unit test to grab the errors from the $post object
Fix custom form fields validation #671
@aoduor - wanted to bring the following to your notice too (Crowdmap) I have added 'Mobile No.' as an additional field in the 'Submit Report' page. The appearing of the field is very random - hope this is in your notice and will get resolved in the new version. |
@manwinder that sounds like the permissions (who can edit, who can view) on the mobile field might be set incorrectly. Does it appear differently when your logged in/logged out? |
@rjmackay I am aware about the feature to set permissions. But here I am referring to the 'Field' itself. As mentioned earlier I have added 'Mobile Field' (Screen shot of settings attached). |
@rjmackay Here is the screen shot of the report page where the Mobile field is not visible despite of not changing any settings. |
@manwinder this is really just issue #744 and should be fixed soon. |
@rjmackay @elleespere Alright - though I couldn't understand #744 completely, but yes I realize the problem may be with Login. My settings of the private field are My understanding of the above setting is that anyone should be able to submit the mobile number, thus 'Mobile No. Fiedl' should be visible to all at 'Submit Report' page, irrespective of the login. Kindly let me know, if my understanding is correct and if after the fix, this functionality would work as per my understanding / requirement ? |
You're understanding is correct. This should work once 2.7 is released |
Thanks @rjmackay =) |
@manwinder please post that issue to the Ushahidi Android repo |
Steps to reproduce:
Expected Result:
An error message should be thrown that only numeric data type is expected for the field.
Actual Result:
Report is saved. No error thrown.
Tested on version 2.5. Tested with the other data types and got the same results. The values submitted in the custom field are not validate. All data types entered by the user is submitted regardless of the data type set in the admin end.
The text was updated successfully, but these errors were encountered: