We have an internal Project management/attendance module implemented in CRM, mostly in JS.
Recently we started facing data issues because our peers started editing/tampering the read-only fields using Browser add-ons like CRM JS Fiddle to enable the fields.
We avoided this situation by user training & enabled audit to see the users behavior. Still new joiners exploring this option & forcing us to micro-manage.
Can we do some fail-proof steps to avoid this flaw permanently? Curious to implement the best approach to stop tampering. Ideas welcome.
Option 1: To intercept the request using pre-validate plugin & skip these fields from updating
Option 2: To move all calculation logic to server, or using calculated fields, etc.
[I don't know if its off-topic, opinion based. still would like to see few response]
When attempting to calculate, validate, or secure data on a CRM form, "God mode" can definitely present issues.
Some options to avoid it are:
Use Field Level Security to make the fields read only.
Use the regular security model to make the entire record read-only.
Use a pre-operation plugin step or synchronous workflow to perform the calculations and/or validate the data.
While it won't prevent the issues, you can write workflows to notify the admin(s) when a user edits a field that should be read only.
You could use JavaScript to set the field to never submit. I have not tested whether God mode overrides this, but since it's a form-based solution we have to assume that a motivated user could figure out how to override it.
Xrm.Page.getAttribute("new_field").setSubmitMode("never");
My personal conclusion and practice is to rely on plugins and custom workflows for data-related tasks, rather than JavaScript and business rules. This has a beneficial side-effect that the logic also works if we're importing data rather than entering it on a form.
When possible, I try to use JavaScript and Business Rules for form layout tasks only.
If you do use JavaScript to show the user immediate calculation results on the form, you may have to duplicate the logic in a plugin.
Another idea (which I have not done myself) would be to add an onChange event to the read-only field(s). That event can recalculate the correct value to frustrate the user's efforts.
For example let's say you have 3 fields: Price, Quantity, and Total.
Price and Quantity are editable, and Total is read-only.
The normal calculation that fires onChange of Price and Quantity is to populate Price * Quantity into Total. Well, you could fire that same calculation when Total changes, which should immediately overwrite any user input with the correct value.
Related
Is it approved to use a html form to build interface to collect user data, convert it to domain model in front end and POST it to server using JSON?
I like to think the user input part as a logical form, event though the server expects JSON. For user it is all the same, so why not just to use a form to collect the data and implement a custom onSubmit method? Another option would be use detached input fields and buttons.
Is this considered a good practice to use forms for JSON POST and what are the good and bad consequences of this practice?
Here is my thought on this:
Pros:
Potentially you can re-use web services to perform form validation as well as acting as a standalone service. Make sure you really have this need before implementing this non-standard method.
Cons:
You are moving away from standard form/post models which is a basic feature of HTML for several years.
Your users will be forced to use JavaScript - not such a big deal in 2016 but you are losing accessibility for... what gain?
You will have to manage this requirement for multiple browsers (adds potential complexity).
Possibly the page load rank will be slower depending on your implementation. This might impact SEO and user experience.
I see a lot more cons thant pros, but maybe your situation truly justify this?
Grouping inputs and submit buttons within a <form> is semantic and good practice, it simply requires calling preventDefault on the event passed to your onSubmit handler to prevent the hard form submit. Your API should speak JSON, and it's trivial to save your form values into state values into state onBlur/onChange, and use jQuery or some other lib to create a JSON post. While its not completely necessary, I cannot think of drawbacks. Fallbacks for the "no javascript" scenario aren't realistic now for most use cases.
i think its a bad approach.
in client side, do client logic, ui logic, etc...
in server side do your processing.
also in many API you will need credentials/token...you sure you wanna share those on cliend scripts (: ??
Here's a common situation: you have a form and you're interested in the submissions of that form. You may add a wrinkle to the situation by adding a server-side validator, or even a client-side validator, but the validators are only provided as a means of ensuring the input you submit is valid at that instance; any state collected between 0 and submission is thrown away and incidental.
Here's a less-common situation: your form has a password/confirm field that you need to wire to work in the obvious manner and wire to display an indication of password strength (and validity). In the past I've seen a lot of "write a jQuery callback for the event handler on change, and call it a day." This is just a more extreme case of needing the state in between to get to a destination, not as an end in itself.
Now a very uncommon situation: you need to track the input of this form because it is a form used by the US government to communicate with our guys in nuclear bunkers in Wyoming. It is certainly important that form input is valid on submission, but we need to additionally know as much as we can about the way it got there. Let's say it is a login form for instance. If we track the sequence of events from 0 to submission and compare it to the past we can detect anomalies in user behavior, for instance. We can determine whether we might be having login servers problems before we hear about them. So this is not always throwaway info.
I want to map the event onChange to some Diode concept, but I'm having trouble figuring out what I ought to do. Here are the options:
I could define a new case class for each field-type and for each object-type permuted, and stick all of them in the root model (seems like a stupid way to do it)
I could define a genericized data structure representing an "un-submitted change in input value" that would also indicate the model and field changing. Seems optimal but maybe unnecessary and a lot of work and hard to do well.
I could use an existing data structure, like one of the Pots, to stand in place for my Scratch data structure. Probably the best idea but not sure which to use.
That's where I am at... any thoughtful advice is appreciated.
This may be something where using a chat would work better, but here are some thoughts on the matter.
There are three places you could store such an event log:
In the state of the view component. Just add the timestamped events to a list stored in the view state. On submission, send this list alongside with the rest of the data.
In the Diode model. Again, store a list of events in the model and submit with the form data.
In the server. Send each event separately to the server and let it worry about what they mean. No need to store on client side at all.
For such transient data, I wouldn't route it through Diode at all, but instead use options 1 or 3 to transmit it.
What I want is to have a funnel reporting where users gave up a form, which fields they completed, and where did they go after they gave up.
Between my researches, I've found two ways of tracking this in Analytics. The first one is creating for each field a virtual page, triggering _trackPageView in completion, and making a goal with a funnel, that has the final page as a goal eg.: /form/open-studio/received, and the other fields as steps, for example: /form/open-studio/name, /form/open-studio/email (along with sending a form, /form/open-studio/send).
This solution was beautiful until I found out that this is inflating my page views report and decreasing the on-page time. I found in this article a solution that involves creating a filter excluding pages that are in a /form "subdirectory" and creating another profile just to track these fields. Although, managing two accounts in JS and everything about this solution just doesn't feel right.
My question about this approach is: Is there a way to create some filter (globally or just in the reports) that doesn't count these /form pages as real page views, but still works to track the funnel?
The second way I found was tracking field completion with events. This solution looks more natural and organic. I could make a goal with a category of events for each form, and each field is a different action. The problems with this approach are: Each event triggered accomplishes a goal (which is not what I want), and GA doesn't seem to be able to create funnels out of events. I may be wrong (and I wish I am), but even this looking like the right option, this funnel report is very important for the client.
Which of these two is the "right approach"? Can I make this work without screwing up the other reports or having to sell my soul to a javascript GA code mess?
Also, if there is any other option instead of choosing between hell and limbo, please, let me know.
Check out Heap Analytics. I think you will find it a better solution both for ease of implementation and ease of viewing results for what you're requesting. The process would be:
Create a Heap Analytics account. (Free 60 day trial.)
Add Heap Javascript snippet to your site. (Just copy and paste, you won't need to worry about implementing additional javascript on each field.)
Let it run for enough time to get a decent sample size (depends on the amount of traffic you get on your site).
Login to Heap Analytics and name the JS events on each page and each pageview.
Create a funnel from the named events to see where the problem is. You can also browse user paths on the Lists report and filtering by users who have done a particular action to see where they are going when they leave the form.
I am facing a strange problem for which i couldn't find a proper solution on web. Though the similar question is asked on Microsoft Dynamics CRM forum under this link, but how to handle this situation is not mentioned there.
I have designed a Workflow in CRM 2011 which should trigger on a single field change (Application Stage) of the application as i have checked Application Stage field under Start when: "Record fields change".
Now the problem is that workflow is triggering twice perhaps one through JavaScript code:
Xrm.Page.data.entity.save();
And another through Update plugin on the same entity which is executed in response to JavaScript code above.
The workflow/process that i have designed is a kind of Master Workflow which has other sub processes that are initiated based on their respective Application Stage. Now in the child process i create an activity related to Application Stage and do other stuff but due to workflow initiation twice it is creating activity and doing other tasks multiple times.
What could be the viable solution to coup with this scenario?
That JavaScript will definitely trigger the workflow once - it is no different from the user just clicking save.
A plugin which performs an update (e.g. service.Update(...)) will also trigger the workflow, that's all intended behavior.
I would start by looking at your plugin, mainly does it have to perform an update call? If you can avoid the double update that should solve your problem.
Did you know that a plugin can make data changes with an update call? If your plugin is registered synchronously and on the pre-event, then any change you make to the target entity object is reflected on the record, this doesn't trigger an additional update - its part of the original message.
For example, if the following code was registered on a pre-event, synchronous plugin the 'new_field' would be populated with "My new value" and no additional update calls are required.
//get the entity
Entity entity = (Entity)context.InputParameters["Target"];
//set new field
entity["new_field"] = "My new value";
//end of plugin
Failing that it might be worth looking into other options:
If the plugin is setting the application stage, why is the JavaScript also setting it?
Is a plugin even required, could it all just go in a workflow?
May you could look at using a do not run workflow field, the field is set by the plugin/JavaScript then when the workflow runs if that field is set it does nothing, but clear the field (not really a recommended option).
Could the plugin trigger the workflows? Perhaps this could be read from a configuration record?
Regarding the plugin, when it triggers on Update, the context will only contain the fields that have changed.
Regarding a Javascript.. I think all the fields get sent to the context so it is like there is an udpate on all of them, so the workflow will fire.
The easiest solution would be to set up a flag on the record, so it only triggers once. This field could be a boolean named "flag" for example. At the beginning of the workflow you can check the value and let it continue depending on it.
For example:
if (flag == false)
Do my logic...........
set flag = true
What do you think?
Cheers,
Mario
Disclaimer: I am a designer with little jQuery knowledge. I will work with a JavaScript developer to realise this, but need to be able to write a detailed specification of my requirement.
I am looking to develop a platform which will track user behaviour via jQuery events API. Events, such as whether a user ‘points-and-clicks’ or tab’s to proceeding form fields will be scored, e.g. ‘point-and-click’ gets a -1 and tab gets a 2.
What is the best way of keeping track of all these event scores? My initial thought is an integer variable which increases and decreases in number depending upon user behaviour. The platform must also be able to:
be developed into a cookie
the value of the variable (if this is the best method) will inform which content to deliver to the viewstate via AJAX
I am happy to receive code snippets and/or written specification suggestions on how best to handle this.
Well, if your need is to be able to write a detailed specification of your requirements then copy/paste your question. It's ok like this.
Or make it more clear by removing your questionnings. If you're writing required specs, don't try to answer on how it should be done, just ask for what has to be done.
Track user behaviour via jQuery events API. Events, such as whether a
user ‘points-and-clicks’ or tab’s to proceeding form
fields.
You can add extra 'project management' infos like
date required
accessibility scope
some web development nice to write for a designer but useless for a developer stuff
budget
data chart / data flow
inputs/outputs