Develop Reference

js / vue app doing CRUD, how can I track what needs updating?

I'm working on a vue app that uses vuex and gets objects from an api. The tables have paging and fetch batches of objects from the api, sometimes including related entities as nested objects. The UI allows some editing via inputs in a table, and adds via modals.
When the user wants to save all changes, I have a problem: how do I know what to patch via the api?
Idea 1: capture every change on every input and mark the object being edited as dirty
Idea 2: make a deep copy of the data after the fetch, and do a deep comparison to find out what's dirty
Idea 3: this is my question: please tell me that idea 3 exists and it's better than 1 or 2!
If the answer isn't idea 3, I'm really hoping it's not idea 1. There are so many inputs to attach change handlers to, and if the user edits something, then re-edits back to its original value, I'll have marked something dirty that really isn't.
The deep copy / deep compare at least isolates the problem to two places in code, but my sense is that there must be a better way. If this is the answer (also hoping not), do I build the deep copy / deep compare myself, or is there a package for it?

It looks like you have the final state on the UI and want to persist it on the server. Instead of sending over the delta - I would just send over the full final state and overwrite whatever there was on server side
So if you have user settings - instead of sending what settings were toggled - just send over the "this is what the new set of settings is"

Heavy stuff needs to be done on the server rather than the client most of the time. So I'll follow the answer given by Asad. You're not supposed to make huge objects diffs, it's 2022 so we need to think about performance.
Of course, it also depends of your app, what this is all about. Maybe your API guy is opposed to it for a specific reason (not only related to performance). Setup a meeting with your team/PO and check what is feasible.
You can always make something on your side too, looping on all inputs should be feasible without manually doing that yourself.
TLDR: this needs to be a discussion in your company with your very specific constrains/limitations. All "reasonable solutions" are already listed and you will probably not be able to go further because those kind of "opinion based" questions are not allowed anyway on SO.

Avoid tampering the Read-only fields in CRM form

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.

How can I prevent someone from altering or avoiding my JavaScript logic when adding buttons to jQuery UI dialog?

I am using a jQuery UI dialog and I am adding buttons to the dialog in JavaScript based on some entitlements logic. (I pass in a boolean from my server-side AJAX call if I am entitled and then I show different buttons based on that flag.)
What concerned me is what is preventing someone from using developer tools like Firebug and putting a breakpoint on that line that does the check and either altering the flag or dragging to skip over that entitlements check.
So my question is specific to adding buttons onto a jQuery UI dialog (because its not like you can add the buttons from the server side since its a jQuery plugin), but I guess it highlights a more general point around any entitlements logic on the client side being "vulnerable". So if there are any general best practices around this point I would be interested (but still looking for an answer to my specific example).
NOTE: I am also doing a server-side entitlement check on POST as a backup, so I am still "protected" but I am still concerned about the point above.

Nothing prevents people from altering client-side code, it is inevitable.
You can, however, add buttons of the kind of "server-side", you just retrieve a string using the AJAX call, which happens to be a JavaScript function that adds buttons. And on the client side do eval() on that string which will execute the retrieved JS function and will add the buttons. Moreover, you can transmit your entire JavaScript code that way, so the client cannot skip anything since all is being executed in the eval().
A quick example:
Server-side function returns
string banana= "alert('test');";
return banana;
and client side does
eval(response.d);
Here is a theoretical example: FIDDLE

You cannot control what clients will do with your scripts, nor what requests they will make of your server. You must design your back-end API (not your JS client) to be the "gating mechanism" between the user and your system. It's best not to think of the JS as part of your system, but as a separate client that you ship as a reference implementation for your API.
But, if you wanted to at least make it difficult for users to mess with your code, you could minify and concatenate your JS scripts with something like Closure.

As the other person suggested, you cannot implement security on the client for exactly the reason you point out. You could use basic auth, or try setting up a token based approach.

Efficient way to track field completion funnel in Google Analytics?

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.

Workflows/Processes triggered when updating the record in CRM 2011

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