We have a feature in our system where the unit tests have been passing for the passed year.
Since yesterday, they are failing and when looking into those unit tests, it seems the unit tests should never have passed because the associating entities are just not there.
My question is whether there is a audit trail for when someone deletes an entity connected to another entity?
When you navigate to Settings - Auditing - Audit summary view you will be able to see all the entries of Audit including Delete action for all the entities across the CRM system.
Click on Enable/Disable filters, then apply the filter whatever you want like Event, Entity, Date, etc to drill down & see the desired data.
Read more
Related
Strange enough that I have to ask such a simple question.
I started automating with UFT and I suppose the correct way to check if for instance my login has worked is to add a checkpoint on the next page.
But how do I do that?
All info I get from google is on how to add an already existing checkpoint to may page. But I don't have any.
Here is how I go about automating:
I add manually the relevant objects to the object repository
I create parameters for my action
I create the code that does the steps on the page
one action per page seems to be fine for me
But in the Object Repository of UFT 14.53, there is no button to add a Checkpoint.
A workaround for me would be to just add another Object and check it's existence and forget about checkpoints. Until I hopefully get an answer here, I will try to do just that.
In UFT there are typically two ways to verify that things are working as expected.
Flow (implicit) - In order to verify that progress in the application is successful (e.g. login) one usually just keeps working with the app, assuming that if the previous step failed, the objects needed for the next steps won't exist and the test will fail due to ObjectNotFound errors
State (explicit) - In order to see that objects have a specific state, checkpoints are usually used. Checkpoints are typically added during a record session, I'm not sure if there's a way to add them directly to the repository. An alternative to checkpoints, which works better with keyword driven testing (no recording), is to use the built in CheckProperty method.
I need to sync entities from Ms Dynamics Crm 2015 - On Premise to my 3rd party application, for this I have set a JavaScript function on the OnSave event of the Entites( eg. account) I can access all of the attributes and send them to my webservice, but the Id (GuId) of the entity!
how can I access the Id (or set it manually) on this event?!
Xrm.Page.getAttribute("accountid") or Xrm.Page.getAttribute("id") both return null, so I can not setValue using them.
Also Xrm.Page.data.entity.getId() returns "" which is probably logical, since Object has not been inserted in the db yet, this is the reason which makes inserting a runtime generated guid for the entety seems doable !
P.S.
I know I can do same thing with plugins, which I have gone through, but the problem there is that when I register my plugin for Update message it gets called a lot of times, (mostly when it has been set for invoice), this is the reason that made me go with the JScript, since the OnSave Event seems more logical than the Update Message of the plugin
As you already found out, records which have not yet been saved have no ID. That's by design (and obvious).
Also, IDs being PKs in the database, they are handled by the system and cannot be touched or hand-crafted.
Your best bet to keep a similar behavior would be a Post-Operation Create plugin living outside the sandbox (Isolation mode: None).
Another good option would be to pull data instead of pushing it: the 3rd party application can periodically fetch new records through any of the exposed APIs (REST, SOAP, SDK ... there are many options).
I have a simple plugin for a custom entity that is set to trigger on Update of my custom entity. It is registered in the Post Operation stage. I have noticed some strange behaviour when I make changes to the Owner field of the record in addition to other standard fields (e.g. text boxes, dates etc).
The plugin fires the first time and the only attributes that come across in the image are all the regular fields. The owner field does not come across.
The plugin then fires again, but the Depth property of the context is still only one (i.e. the plugin is not getting triggered by changes made in the plugin code). In this run of the plugin, the attribute that come across is only the Owner field.
My theory is that because the owner fields are 'special', the CRM is doing two different requests - one to change the regular fields, and then another request for changing the owner via an AssignRequest. However, I cannot find any 'official' documentation for this behaviour.
Can someone explain why this is happening?
I am running Dynamcs CRM 2013 UR2
The Update event fires during the Assign event. So if an assignment takes place your plug-in will execute. The same is true for SetState - if you activate/deactivate a record an Update event takes place. These items are not documented in the SDK.
A good practice is to use Attribute Filtering on your Update plugin so it only fires for the fields it is concerned about - this will, assuming it is isn't looking at the owner related fields, avoid it firing twice. If you have logic specific to record ownership you would put it in a plugin that is registered on the Assign event.
I was not able to find official documentation about this, but I think Assign message is what you are looking for (if the entity is user-owned. See http://msdn.microsoft.com/en-us/library/gg328576.aspx. I would strongly recommend that you specify Filtering Attributes if you are registering a plugin on Update message. You could also debug your plugin and inspect MessageName property of plugin context and see what message gets triggered. I hope this helps.
I understand that a plugin registered for pre-validation executes outside of the database transaction but I'm not sure I can think of a scenario when this would be preferable to pre-operation. Can someone give me an example of where pre-validation registration might be useful?
We have a few plugins registered on the 'PreValidation' event although this is on premise, not online.
I did not write these specific plugins myself but I can describe one and give the justification for using 'PreValidation' rather than 'PreOperation'.
Entity: Account
Event: Delete
Logic: Plugin runs pre validation. Checks that there are no contacts referencing any of the account's addresses. If any are found, stop execution. If not, delete account.
e.g.
Account 'Stackoverflow' has address 'Jeff Attwood's House' and Contact 'glosrob'. 'glosrob' is referencing 'Jeff Attwood's House' through a customisation. If a user selects to delete 'StackOverflow', we should detect 'glosrob' is referencing an address and prevent the delete.
The reasoning behind this was the developer found that at the PreOperation stage, some aspects of the delete had already happened, namely the cascade deletes. The logic of the plugin requires us to check all contacts - by registering at PreOperation, contacts under the account had already been deleted, rendering the check obsolete.
In our previous scenario, when the user selected to delete 'StackOverflow' Account, the Contact 'glosrob' would be deleted before the plugin runs. Therefore when the plugin did run afterwards, it would allow the delete.
As with most things in CRM, it all comes down to requirements and solutions, but I think that gives you an idea of why/when you might use a PreValidation stage. We have a few others with similar reasoning that run on the 'Delete' event.
I know its very old post, came here while digging for an answer for the same question...
Later I found one key point from MSDN on the same topic and i thought it would be helpful If I post the infromation over here for all..
The Prevalidation plugin would happen prior to the security checks. For ex: If an account is "VIP" account and you dont want this account record to be deleted (no matter even he is a super user/admin), then this better can happen in pre validation. Because at that time you are not really bothered about who the user is and what sort of permissions he has (even he may not have any permissions to delete any records in the system), CRM will go and check the database for the user's security roles during the pre operation and that is where the first database hit would happen.. before that it self, we can stop the exucution of the plugin based on our validation rules..
I hope that make sense...
Thank you
Regards
Srikanth
I wanted to get your opinions on the easiest way to track changes that users make when they do CRUD events. I am working on a system where the users are less interested on permissions, but really want to have a sophisticated log of what changes a user made. I am using ASP.NET MVC 3, EF, and NLog.
Any advice is greatly appreciated :)
Steve
I use a convention based approach. Each entity has an associated audit entity which includes all properties from the base entity plus information on the change, including whether it was successful or not. I override the SaveChanges method on the DB context. For each entity being changed it creates an audit entity from it holding the new values. It attempts to save the changes, then uses a separate, auditing context to save each of the audited entities with the results of the save operation. I use an injected utility in the data context to get access to the current user (via HttpContext.Current for web, via the Environment.User for non-web) when constructing the audit entities.
I blogged about an earlier version of this for LINQ to SQL at http://farm-fresh-code.blogspot.com/2009/05/auditing-inserts-and-updates-using-linq.html. You should be able to get the basic idea from that.