I'm building a CRM solution for a customer to replace their legacy Access databases. They have cases with case numbers that are referenced by external documents and want to keep them as the case number in CRM. I wrote a plugin that auto-increments and assigns case numbers when new cases are created and it works great. The problem is when I try to import their old data. I map their old case number field to the case number field in the import wizard but the imported cases get a new case number like PRE-12345-asdf.
Case number can't be updated by a workflow.
Ideally I'd like to be able to use the built in case number, but would I be losing out on any functionality if I just hid the built in case number field and added a custom field for it?
You can create a custom field to track your own Case Number instead (in this case we just called it "casenumber").
On the Case Entity form onLoad event we put the following function that updates the Case Number shown in the Header area as well as the Page/Tab title to be our custom field:
function UseCustomCaseNumber()
{
var caseNumber = Xrm.Page.getAttribute("new_casenumber").getValue();
document.getElementById('form_title_div').childNodes[2].innerHTML = caseNumber;
parent.document.title = "Case: " + caseNumber + " - Microsoft Dynamics CRM";
}
The built-in case number cannot be overwritten. Hiding it and using your own field seems relatively common, and won't cause you any issues.
Related
I am trying to limit entities that the user can select from on "Regarding" field on Appointment form and set some default views used by these lookup fields.
The big idea is that when user is entering data in the field itself, the results should be provided from default view for this lookup, e.g. "Contacts I follow", but when user enters "Lookup more records" pop-up the default view should be swapped to "All contacts".
This field can look up in many entities, e.g. Account, Contact, Billing, etc., and I want to limit it strictly to Accounts only.
So far I've found two ways of doing it:
1) Add filters to lookup fields, so that any records not fulfilling given criteria will not be shown. This is done using addPreSearch JS function from Xrm lib, like this:
var addEventHandler = function (defaultView) {
Xrm.Page.getControl("contactid").addPreSearch(function () {
addFilter("contactid", defaultView)
});
}
var addFilter = function (entityName, defaultView) {
var filterXml = "<filter type = 'and'>" +
"<condition attribute='contactid' operator='null'/>" +
"</filter>";
Xrm.Page.getControl("contactid").addCustomFilter(filterXml, "contact");
Xrm.Page.getControl("contactid").setDefaultView(defaultView);
}
(This is just sample code, not actually applied to the Regarding field)
2) Second option is to use undocumented solution by using setLookupTypes function on the field itself, like this:
var limitLookupEntities = function () {
Xrm.Page.getAttribute("contactid").setLookupTypes(["contact"]);
}
var changeDefaultViewForLookup = function(viewGuid){
Xrm.Page.getControl("contactid").setDefaultView(viewGuid);
}
The issue:
The problem is that as mentioned earlier, "Regarding" field can look up in many entities. Limiting them using the solution 1) is tedious, having to create as many filters as there are entities and applying them one by one to the field doesn't seem the right way to go. However, the way I implement this, the default view behaviour works as intended - the look-in value is only changed for the pop-up window.
Solution 2) is way easier to implement, and won't require any changes in the future if any new entities would be added to relationship with "Regarding" field, but the default view is applied to both "in-field" and "pop-up" default view.
The solution I'm looking for needs to do the following:
It should limit the search to specified entity only
It shouldn't require any maintaining after being implemented, e.g.
in case new entities are introduced to "Regarding" field.
It should be generic - I might want to be able to parametrize it and use it on other forms
It should apply the default view change only when user opens the pop-up search window
Is it even possible?
The CRM version I'm implementing this on is 8.2 on-prem.
I have been investigating ways to synchronise incremental changes with dynamics crm.
I stumbled accross the MinActiveRowVersion property of RetrieveMultipleRequest
var orgService = serviceProvider.GetOrganisationService();
using (orgService as IDisposable)
{
var accounts = orgService.RetrieveMultiple(new QueryExpression("account") { ColumnSet = new ColumnSet("accountid") });
Console.WriteLine("min active is: " + accounts.MinActiveRowVersion);
}
This property always returns "-1" during my testing, even when I am trying to simulate transactions going on in the background, but its tricky to do.
My understanding of MinActiveRowVersion from a SQL perspective comes from here:-
[http://technet.microsoft.com/en-us/library/bb839514.aspx][1]
So my question is, is anyone able to clarify exactly what this MinActiveRowVersion property is, because I can't find anything useful in the SDK documentation!
To the best of my knowledge and experience it is never used and will always equal-1. Under the cover it is hard coded as a long and converted to a string when the EntityCollection object is built - so it will always be -1.
The SDK defines it as "the lowest active row version value" which implies it is related to SQL row versions, but CRM does not make use of this field. It is defined the same in the CRM 2011 and CRM 2013 SDKs.
In CRM 4 we had the BusinessEntityCollection, which was EntityCollection's predecessor. It had an unused string property called Version.
My guess, back when the CRM 2011 was being designed it got added for some potential functionality - which didn't survive - and never removed before it went RTM. Once it was released the product team didn't want to change the class definition and break existing code so they just left it there to live on returning -1.
MinActiveRowVersion is returned in the fetch response if the fetch query contained the attribute min-active-row-version=1. (In the same tag where page and distinct attributes are specified.)
We rely on this behavior for years. (And yes, we use it for synchronization of changes. Rowversion appears to be the only reliable tool. Note that not all Dynamics entities have Rowversion column. E.g. duplicaterule entity does not use it. For such entities we use modifiedon column.)
Here are some citations from $MS documentation:
##DBTS = The last-used timestamp value of the current database.
MIN_ACTIVE_ROWVERSION = The lowest active rowversion value in the
current database; ##DBTS + 1 if there are no active values in the
database.
A rowversion value is active if it is used in a transaction that has
not yet been committed.
I would like to know if it is possible to disable the validation for a subset of modelelements which are specified in the metamodel.
The problem is that I'm getting some validation-errors from the Xtexteditor while writting my dsl-file. So my idea is to disable the validation for exactly this modelelement.
I try to build a real simple textual notation and want to serialize the (valid) model while saving the file. The saved model is modified during the saving process, so it is
valid at the end.
Regards,
Alex
Lets beginn with the grammer:
I'am working on an imported metamodel (UML2):
import "http://www.eclipse.org/uml2/4.0.0/UML"
Then I create all the necessary parserules to define a classdiagram. In my case the problem appears
in the parserrule for associations between classes:
AssociationClass_Impl returns AssociationClass:
{AssociationClass} 'assoc' name=ID'{'
(ownedAttribute+=Property_Impl)*
'}';
And of course the parserrule for properties:
Property_Impl returns Property:
name=ID ':' type=[Type|QualifiedName]
(association=[AssociationClass|QualifiedName])?
;
Now some words to the problem itself. While editing the xtext-file in the xtexteditor of the runtime eclipse, the build model is validated. The problem is here that the metamodel itself has several constraints for an AssociationClass (screenshot not possible yet ):
Multiple markers at this line
- The feature 'memberEnd' of 'org.eclipse.uml2.uml.internal.impl.AssociationClassImpl#142edebe{platform:/resource/aaa/test.mydsl#//Has}'
with 0 values must have at least 2 values
- The feature 'relatedElement' of 'org.eclipse.uml2.uml.internal.impl.AssociationClassImpl#142edebe{platform:/resource/aaa/test.mydsl#//Has}'
with 0 values must have at least 1 values
- The feature 'endType' of 'org.eclipse.uml2.uml.internal.impl.AssociationClassImpl#142edebe{platform:/resource/aaa/test.mydsl#//Has}'
with 0 values must have at least 1 values
- An association has to have min. two ownedends.
And now I wanted to know if it is possible to disable the validation for exactly this modelelement. So I can hide the errorinformation from the user. Because I want to serialize the created xtextmodel in the next step and will do some modeltransformations.
Seems like UML registers this validator in the global singleton registry. So you basically need to avoid using the registry. You can do that by binding a different element in your runtime modul:
public EValidator.Registry bindEValidatorRegistry() {
// return an empty one as opposed to EValidator.Registry.INSTANCE
return new org.eclipse.emf.ecore.impl.ValidationDelegateRegistryImpl();
}
We are beginning to allow multi-national registrations and have the requirement to split the phone number entry in the OnePage checkout billing.
We want to add Country Code and split the rest into Area Code Number and Extension fields. Then we will need to concatenate them into one before storing them.
How would I accomplish that?
Could you not just use a hidden field and javascript? So add 2 fields, then use onchange="phonecat()" on each to trigger a function that concatenates then values and assigns them to the pre-existing telephone field, which you have changed to be type="hidden".
Something like the following in JQuery:
function phonecat() {
$(function(){
newphone = jQuery("#initialphone").val() + jQuery("#latterphone").val();
jQuery("#billing\\:telephone").val(newphone);
}(this.jQuery));
}
I've not tested this exact solution, but I've used something similar in the cart. Only the (now hidden) proper field will be passed and used.
File is .../persistent/checkout/onepage/billing/phtml in 1.6 (without persistent/ earlier). And you'll need to define the function somewhere too.
When I have a custom entity Referral, the primary attribute is a refid and this is what shows up in associated views (as the link text that opens Referral form). I need to change this name to something that is generated from entity attributes). Something like:
Referral.ToString() { return ref.id + " " + ref.first_name + " " + ref.last_name + " "; }
instead of the default ref.id.ToString() -- or however it works.
Is this possible via the MS CRM 4? I fear it might not be (having clicked through the gui customizations for a while), but maybe I missed something.
If not, what is the most elegant way of doing this? A javascript function would need to be somewhere global (otherwise it would need to be copy+pasted to every form/view that mentions Referral). Also, the javascript function (I assume), would need to do at least one additional XmlFetch on every view.
Any suggestions, comments, ideas welcome. I've started modifying the MS CRM at work and I keep hitting issues that I feel have been solved by open source python web frameworks over and over again. Please help a poor soul at work :)
I've found the easiest way of handling this is to populate the primary attribute with the fields you want concatenated. You can do this in javascript on the form, a plugin registered to fire on create and on change of any of the attributes you want, or a combination of both.
Unfortunately, there's no (supported) way to change the primary attribute after create of an entity. You'd have to recreate the entity with something like prrfix_name as the primary attribute, and then combine your id, first_name, and last_name fields.
Trying to alter CRM's behavior re: displaying the primary attribute would be completely unsupported, and probably pretty technically daunting and take a huge chunk of time. I'd just take the time hit to recreate the entity with a new primary attribute.