If one has to perform business rules related validations and some cross field validations; on data entered in html-form-fields on screen, how can it be done?
Does the Moqui framework provide any inbuilt-support for this?
Is there any guide/tutorial available for this?
Update:
Hi David, thanks for your time. Below is the detailed requirement for validation.
1) Need to show the validation message on submit (before the request is sent to server) rather than after the request is processed on server.
e.g. When I open a dialog/screen to create/update some record, than I pass invalid number(e.g. 'abc') value in field and click submit;
the FORM gets submitted and the response (on next screen) is:
The value [abc] is not valid for type [java.lang.Long] (for field xyz) etc.
So, how can the FORM-submission be prevented and how to show message to user before submitting and on the same screen not on next screen? (ie.
how to implement validation similar to javascript validation at field/FORM-submit level). And this may be required not only on
just one screen but on many other screens may have thier own screen specific different validation rules for various fields.
Traditional way of adding bunch of .js files in header/footer doesn't look right; because how all the FORMs would know(without making
some changes to how the FORM gets generated) which js-function to invoke and when? And also I don't want to make any custom change in
framework which may not be compliant with any future upgrade of moqui or may require lot of re-work to integrate it smoothlessly for future upgrades.
2) Cross field validation i.e. filed1 is to be validated based on result of some calculation of values in field2 and/or field3 etc. How can this
be done on client-side?
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
In my application, I will have clients trying to book some slots. For this, the client will give some input and based on that input, I have to first create these slots and then return them to the client. Then after getting the slots, the user will book one of these slots. This "book" action is not creating any new resource but simply modifying 2 existing resources.
How do I design my URIs and what methods should I use?
EDIT:
I have 1 existing resource whose URI is: /api/v1/vehicle/id
Using the application front-end a user will fill some form data, with fields date and booking-type and submit it. Then this data will be used by the backend to "calculate" (no resource called slots exists currently) booking slots available to the user. These calculated slots will then be saved in the DB and returned as a response to the user. Out of these slots, the user will book a slot. However, this book action will not create any new resource, instead it will simply modify an existing vehicle resource (add booking related data to it) and the slots object returned by the previous request. I want to create a REST API for this.
I was thinking of doing it like this:
POST /api/v1/slot (1)
PUT/PATCH /api/v1/vehicle/id (2)
PUT/PATCH /api/v1/slot/id (3)
First, I am not sure if I should use PUT or PATCH here, in both (2) and (3). I will only be supplying partial updates to the request. Second, when the user selects a slot and clicks on book button, the front end can only send 1 request to the server. But here, I need to modify 2 resources. How do I do this? I guess I should create 1 URI like /api/v1/createbooking and use the POST method. Then in my backend call 2 different methods to update vehicle and slot objects. Is this URI structure and naming good?
How do I design my URIs and what methods should I use?
How would you do it with web pages?
It sounds like you would have the user navigate to a form which collects the date, booking type, etc. The user submits the form, and the information is sent to the server; because this is not an essentially read-only operation, we'd expect the form to indicate that the POST method should be used.
The server would make its local changes, and present to the user a new form, with the input controls presenting the available options. Once again, choosing a slot doesn't seem to have read-only semantics (we're passing information to the server), so we would see POST again.
What are the URI targets? One way to choose which resources should handle the POST requests is to consider the implications of cache invalidation; because caches know to invalidate the target-uri of a successful POST request, it can be useful to target a resource that is likely to change when the request is successful.
My guess would be that first post would go to the resource that presents the slot choices (since what we are doing is generating new choices for the customer).
For the second submission, since the representation of the vehicle is what is going to be changed by selecting a slot, it makes sense to send that POST request to the vehicle uri.
In general, think about how you read (GET) the changing information from the server; you change that information by sending some request to the same URI.
I am not sure if I should use PUT or PATCH here
PUT and PATCH are typically available together, not as distinct things. They are two different methods for sending a replacement representation of a resource.
A simple example: if you wanted to change the title of /home.html, you could either PUT the entire HTML document with the new title, or you could PATCH the HTML document by sending a patch-document in some format that the server understands.
In other words, both of these methods have remote authoring semantics; we normally would choose between them based on considerations unrelated to your domain model (if the document is small relative to the size of the HTTP headers, a client would usually choose PUT for the additional idempotent semantic guarantees. If the document is really big, but the change is small, we might prefer PATCH).
I need to modify 2 resources.
There's no rule that says a request may only modify one resource. The side effects of the changes may impact the representations of several resources (see 4.3.3 and 4.3.4 of RFC 7231).
What's tricky is telling general purpose clients (and intermediate components) which cached representations are invalidated by the change. Out of the box, we only have semantics for the effective request uri, the Location and the Content-Location. Location and Content-Location already mean something, so you can't just hijack them without the potential of introducing a big mess).
You could do it with Linked Cache Invalidation, using "well known" link relations to identify other documents that have been changed by the request. Unfortunately, LCI doesn't seem to have achieved the status of a "standard", so we may be out of luck for the time being.
Currently creating an automation using zapier which should change the lead owner in salesforce when the event takes place. It successfully reaches salesforce but does not actually change the "lead owner" but it is instead reflected in the lead history section. There is no clear salesforce workflow or rule in place which should prevent this automation from occurring.
When the automation executes as you can see above, the lead owner successfully changes in the lead history but it does not actually change the lead owner of the actual lead so we are manually having to go back and change this.
Has anybody else faced similar issues when working with the salesforce API when changing the lead owner and if so what was the solution?
Check Lead assignment rules. It's separate area in Setup, different from workflows, flows, process builder and triggers.
You probably have an active rule that runs on update, not only on insert. Your API call works OK, changes the OwnerId field but then the assignment rule overwrites that. That's why you see it as 2 entries in history.
You can also confirm what's going on byenabling debug logging on the integration user and check if it captures anything.
Optionally you could also suppress the assignment rule during the update. This is... questionable. I mean talk with your SF admin first, if you suppress the rule then you moved bit of logic out of salesforce. 2 months later nobody will remember why something doesn't fire, it's cleaner to just modify the rule to skip these records.
If Zapier uses SF REST API there's a HTTP header it should send, Sforce-Auto-Assign: FALSE. If it uses SOAP API - similar thing will have to be set in the SOAP message's header, check the WSDL for exact syntax?
We solved this, just broke down the issue and resolved by doing the following (This was beyond the standard salesforce scope of support as we use custom prefill URL's for anybody wondering):
Create a new hidden field called something such as 'tmp_owner'
Assign the new lead owner ID to a new text field called 'tmp_owner' which is hidden on
the lead field to other salesforce org users
Added a salesforce workflow rule when this 'tmp_owner' is populated replace the 'lead owner' field with the data.
Thank you for answering my previous questions and I appreciate the effort put in by you in developing Moqui.
In the field tag there is an attribute of validate-parameter so could please elaborate the use of it and how to use that attribute. Thanks in advance :-)
To be specific, it sounds like you are looking at the XML Form field element (form-list.field, form-single.field).
A form field can be validated based on the validation settings in a service parameter (there are many validation options there) or an entity field (just a couple validation options there). This is done automatically when a form submits to a transition that has a single service-call element (i.e. not an actions element), and these attributes are populated automatically. You can also specify manually which service/parameter or entity/field to use for validation.
This is all part of the support in the framework to do client side validation with JavaScript using server-side validation settings. Note that the validations are also done on the server, but you don't have to define/implement them twice.
In my application I have a file upload (actually multiple file uploads), and I managed to do it without using a gem/plugin like (Ex: carrierware).
But when my form validation fails it loads the from data with error messages, but not the values in file_fields. My client wants to keep the values as it is when form validation fails.
I have search a bit and found out that for security reasons, its not allowed to set values to file fields. So can someone proposed me a possible workaround for this (to keep the selected file path when a form validation fails)
Please note that I'm not using Ajax form post here, this is simple default HTTP post
I'm running on ruby 1.9.2 and rails 3.0.0
thanks in advance
It is not possible to do with what you are asking. Due to security reasons, the value of the upload field can not be set, or even styled with some browsers.
The best bet:
Upload the file before the validation, then discard if the user cancels.
Use ajax, or a fancy form of uploading. (Store path in hidden field, and then upload with some form of ajax/flash.)