I've built a Custom Plugin for CRM 2011. Basically, the same plug-in has been deployed in two different environments: Test and Pro.
These environments are obviously twins. Same entities, same configurations etc..
The plug-in, triggers on update of a specific boolean field. On true value, triggers and add a contact to a list. So, with the same logic, on the same field set on false, triggers and remove the contact from the list.
Now, on "test environments", it triggers on both situations. But on "Pro environments" , when the boolean field it's set on false, it doesn't trigger!
I discard any supposition of a logic bug implementation. For the reason that it works well on the the first environment.
Above, it doesn't write any log in this case. And it makes me more convinced that it doesn't trigger at all.
Does anybody knows , what could be the problem?
First, make absolutely sure that your theory is correct. Throw an Exception right at the top of your plugin, and see if you get the Exception pop-up in CRM on both True/False. If you do, then the plugin is firing on both a True/False update and there is something wrong with your code - I can't imagine what it is since it works in dev, but at least you've proven that it isn't the CRM plugin infrastructure's fault.
If you don't get the pop-up Exception for the False scenario, the only other possible answer is that CRM's plugin infrastructure doesn't think that field should be updated. When the screen refreshes after an update to False, does that field still show False or does it go back to True? It is possible to "cancel" a field update by removing it from the field list of the entity that gets passed into your Pre-Operation plugin - is it possible there are other plugins that execute before this one and maybe cancel that field update?
Last thing I can think of: you are saying Update but do you mean Create? If that boolean field's default value is set to False in Prod but not in Dev, when you create the entity, that field won't be included in the field update list (and thus not fire your plugin) if it is set to False because the system already knows the default value to use on a Create is False.
Related
When I create a new record on the Service Request (SR) application (Maximo 7.6), I would like to set the required Reported Date (SR.REPORTDATE) field blank. Before save action, the user will input data into that field. I wonder how this could be done?
Thanks for the help.
If you look in Database Configuration to see if REPORTDATE has a Default Value, I think you'll find &SYSDATE& in there. If I'm right, then you can delete that default value, save your changes, and apply your changes. Otherwise, you'll need to do as #Dex suggested.
My mind immediately goes to an automation script. A default value control or the default value setting in Database Configuration may work too and is recommended before a script if you have the expertise to confirm or deny this theory.
As for the automation script, I think you can create one with an object launch point on SR on the "add" event. The script would simply set that field to null, which shouldn't change the "required" flag either, so the rest of your needs will still be met.
mbo.setValueNull("REPORTDATE");
I am looking to create a workflow that will populate any mandatory fields that do not contain data when a company is deactivated. The mandatory fields are either not populated because of legacy data or because the mandatory fields have changed since the record was created.
The issue I get is that the mandatory field check takes place before the workflow is triggered.
My workflow looks like follows:
If Status = Inactive
If Company Name does not contain data
Then update to ‘Test’
I have come up with a possible solution:
• Create a new button in the ribbon that runs the workflow on-demand and apply permissions to this button.
If possible though I would like to do this through a workflow that is triggered on clicking of the ‘Deactivate’ button. Any ideas are welcome.
In your situation the record will not be saved until the mandatory fields are filled, and a workflow cannot be triggered if a record is not saved first.
An approach to solve this situation is to write a JavaScript attached to the OnSave event, but you need a rule to be able to identify the legacy records, so this JavaScript (that will fill the mandatory fields for you) will not run for normal records.
This approach is not tested, but with some tweaks should work.
I build a plugin that runs in account update message that makes some validation not to duplicate the record. But if I try to disable that account or merge with another one it triggers the plugin.
How can I tell if the plugin was triggered by an activate/deactivate/merge action, or event mode like the one in CRM Dynamics 2011 Save Event Arguments Reference?
To add to Pete Oakey's answer, you can actually tell your plugin to fire only when certain fields are changed at the registration phase, in addition to testing this in actual code # runtime, by changing the "Filtering Attributes" of the plugin step. So unless your validation logic specifically needs the StateCode/StatusCode attributes to correctly process, you can filter those two attributes out, or just include the attributes your validation logic needs.
Original answer:
I believe you can reference the IExecutionContext.Depth Property of the IPluginExecutionContext object.
Every time a running plug-in or Workflow issues a message request to
the Web services that triggers another plug-in or Workflow to execute,
the Depth property of the execution context is increased. If the depth
property increments to its maximum value within the configured time
limit, the platform considers this behavior an infinite loop and
further plug-in or Workflow execution is aborted. The maximum depth
(8) and time limit (one hour) are configurable by the Microsoft
Dynamics CRM administrator.
So you can use an if statement to check if Depth > 1.
One way would be to compare the before and after values of what's changed on the account entity in the plugin. For example if you have only have active (if that's the right property name) in the values - you can look at the after value to see what's happened.
Another way would be to add a specific plugin for these messages and set some property/flag which you can check in the update plugin. Obviously this would have to run before the update plugin.
I want to add a field "Single Line of Text" to my custom entity which should be unique.
How can I make Crm to throw me an exception when I try to create the duplicating value of the
record?
You have to create a plugin for this requirement which handles the Pre-Create/Pre-Update step for this entity. In this plugin you have to check whether the passed value is unique or not. If it's not, you throw an exception which cancels the operation and displays a dialog to the user (if the plugin runs synchronously).
throw new InvalidPluginExecutionException("Value passed for 'attribute' is not unique.");
You can't do this through configuration, as far as I know.
You would need to use some client code to query existing values for that field to see if the newly entered value is unique. You could use something like jQuery and the CRM REST service (ODATA) to perform an asynchronous validation on the field; it might not be instant though, you may need to consider how this is presented to the user.
Alternatively you could do this with workflow, but that'd be even less instant - it'd probably have to be triggered after the save.
Another option is to create unique SQL index directly in database.
I'm not a Notes programmer, however, for my sins, have been working on some Notes features for an in-house project recently. I need to enable/disable editing of a field depending on circumstances. It seems to me to be a fairly standard feature, I need, but I can't find any information on how to do this anywhere.
In form setup (and other field's onchange) code, something like the following:
if some requirement = true then
textField.enable = true
else
textField.enable = false
end if
I've seen other places where there's a workaround of conditionally hiding paragraphs based on some code, having 2 paragraphs with opposite hiding conditions, one with an editable field, the other with a computed field. However, I don't know enough about Notes to see how this is implemented (I can see it done on other forms, but there seem to be some 'magic' steps within Notes which I either can't see or don't get).
[EDIT]
The reply from Kerr seems to be what I'm looking for, but I still can't find out where the InputEnabled property is located. Should have said in the initial question, I'm using Notes 7.0.3.
In fairness, it doesn't matter what the circumstances are for when to enable/disable the field, it's just some boolean condition that is set, in my case only on form loading so I don't even have to worry about this changing dynamically while the form is displayed.
I've got a few issues with Notes, my largest bugbear being that it's so tied so tightly to the Designer UI, which is utter shite. I can do this sort of thing programmatically in most GUI languages (C#, Java, Delphi, even VB), but I need to open property boxes in Notes and set them correctly.
This would be OK as an optional method, but forcing you to go this way means you can only work as well as the IDE lets you in this case, and the IDE here seems to actively work against you. You can't open multiple functions/scripts, you can't swap from one script to another without going back to the menus on the left, you can't easily search the codebase for occurrences of variables/fields (and believe me, this is a major failing for me because either Notes or the internal codebase in my case seems to make a lot of use of global variables!), you can only work with fields through the property boxes that get displayed, you can't edit code in Designer while debugging through the main Notes client.
While the Java side of the coding is better than LotusScript, it's still fairly crappy (why can't you debug INTO Java code?? Why do you need to re-import JAR files for each Java class, does each class have a different CLASSPATH???). Possibly this was improved in Notes 8, I hear it's based on Eclipse. Does anyone know whether this is true or not?
It would help to hear more specifics about the 'circumstances', but the most common way to handle this is to use a hide when formula on the field you want to enable/disable.
Technically you are not enabling or disabling the field, just hiding it, but usually that works just as well.
Since there are few events to work with in Notes, developers commonly use the document refresh as the 'event' to cause the field to hide or show.
Let's assume you have two fields called TriggerField and Subject. Say also you want to disable the Subject based on a value in the TriggerField. The easiest way to do so is to set the TriggerField as a Dialog List type and check the "Refresh fields on keyword change" option. This means when the value of the dialog list changes, the entire document will get refreshed.
Then in your hide when formula for the Subject field, you specify your criteria for when to show or hide that field. Anytime field values change, followed by a refresh of the document (i.e. form), that hide when formula will be re-evaluated.
There are other ways, depending on your circumstances, to solve this problem. If you want to let the user refresh the form themselves, put a button on the form that calls the #Command([ViewRefreshFields]) command. You can add any other formulas to that button before the refresh command if you want to make other changes to the form at the same time.
Another option is to make a certain field display-only. Then create a button that runs LotusScript to allow users to change that display-only field. In the script you can propmt the user for a value, set the display-only field, and then call for a document refresh.
In ND7 and up if you want to just disable the field for input, write an appropriate formula in the InputEnabled section of the field you want to disable.
So I have two fields one called Trigger, a checkbox with the value "On" and another Subject that is a text field. When Trigger is checked I want the value Subject to be enabled.
I simply put the following formula in the Input Enabled element of the field Subject:
Trigger = "On"
I also want this to be recalculated whenever the value of Trigger changes so I select the "Refresh fields on keyword change" option on the Trigger field.
If you're stuck in an older version you need to to hide paragraphs appropriately.