I'm having this issue on several server environments.
We have a list at the site collection root. There is a site column created as a multi-value lookup on that list's Title field. This site column is used in document libraries in subsites as a required field. When we upload anything but an Office 2007 document, the user is presented with the document metadata fill-in screen (EditForm.aspx?Mode=Upload), the user fills in the appropriate data (including picking a value(s) for this lookup), and clicks "check in" - the document is checked in as expected, with the lookup field's value filled in.
With an Office 2007 document, this fails. The user selected values for the lookup field do not ever make it to the server - no errors are thrown, but the field is not saved with the document. We have an event listener on these document libraries, and if we inspect the incoming SPListItem on the event listener method before a single line of our code has run, we see that the value for the lookup field is null.
It smells like a SharePoint bug to me - but before I go calling Microsoft, has anyone seen this & worked around it?
Edit: the only entry I see in the SP trace logs relating to the problem:
CMS/Publishing/8ztg/Medium/Got List Item Version, but item was null
Wound up having to open a ticket with Microsoft for this one, and found a bug in the MSDN documentation to boot.
In order to get a multiselect lookup, we had been setting the "Mult" attribute in our lookup field CAML to "true" in the XML we passed to SPFieldCollection.AddFieldAsXml. However, even though the API will throw no errors & appear to work in the UI, this clashes with how Office 2007 & 2010 documents & their SharePoint integration works.
The official, supported way to add a multiselect lookup field is to use the LookupMulti field type in the Field CAML. Doing this, and setting the "Mult" attribute to "true" gives the result I was looking for.
The MSDN documentation for "Mult" has still not been updated for the SP 2007 documentation, and can safely be ignored as it is completely wrong.
Related
We've recently enabled the Unified Interface on our Dynamics 365 CE web client and noticed that the fullname is missing from the Contact forms and several views. It is there when we open the Form editor, but when we're running formContext.getAttribute("fullname") it returns a null.
It's causing us a big headache as we're using the fullname basically everywhere: in forms, views, Document templates, JavaScripts etc.
Has anyone come across this problem or knows a workaround without having to replace the fullname with first and last name everywhere in our environment?
According to Microsoft it's officially not ready before April 2020 (https://learn.microsoft.com/en-us/power-platform/admin/about-unified-interface#capabilities-not-yet-on-unified-interface), but we need to start testing before that.
Many thanks in advance
Composite control is not available in UCI yet. So the popup will not be showing up to do data entry. That means the Full name field will display as the child individual fields, ie. First name & Last name. The data changes in any of the First name or Last name will replicate to Full name field.
Only changes needed is in form scripting. Whenever/wherever you are accessing the Full name field like formContext.getAttribute("fullname") just switch it to formContext.getAttribute("firstname") + " " + formContext.getAttribute("lastname") if the script is executing in UCI.
I just tested this quickly in my UCI. Also views showing the Full name field without issues. Templates should not be a problem if data is there. Only problem is in form, so the above script will solve the issue.
I am trying to make a field optional in the Dynamics CRM
The name of the entity is Case and the internal name of the field is customerid
When I try to change it from mandatory to optional, I get the below error message
You can not complete this action for this component because of the
configuration of its managed properties.
this is happening in Dynamics CRM online
I'm pretty sure you won't be able to.
It's one of the few fields where mandatory behaviour is enforced at the platform level, whilst most mandatory fields are enforced only on the user interface.
If I remember correctly, tring to create a case without a customer via the API will result in an exception.
Looking at the managed properties for the customerid field on my recently provisioned CRM Online, shows that I'm unable to change the requirement level - I don't even get the option for setting it as optional.
I wanted to remove the field from the form, but I was not able to do it from the UI
So I used XRMToolBox.
There is a plugin called as FormXML Manager, enable it in the XRMToolBox and load the entities. Once this is done you can remove the required field and publish the form
Does anyone know how to use C# to get the Default Display String for a Message?
The Default Display String is the first column displayed when you open a Solution, select an Entity (such as Case), and then select Messages. It contains values like "A Parent Case cannot have more than {0} child cases. Contact your administrator for more details."
The DisplayString Entity seems like the right place, but it only has the CustomDisplayString and the PublishedDisplayString, and not the default display string. Microsoft have confirmed that the Default Display String is not in the DisplayString Entity, but they don't say where it can be found...
I have tried searching the Metadata Browser, and even went trawling through the Organisation and Config databases, but no luck.
Any help greatly appreciated ...
While this doesn't answer your question directly, it's a clue.
I checked a bit in the database, then searched for the Account entity message "Existing Account?" in the file system.
It's in this DLL:
C:\Program Files\Microsoft Dynamics CRM\CRMWeb\bin\Microsoft.Crm.Application.Components.Strings.dll
As far as accessing strings in that DLL from C# goes, I'm currently at a loss. You might want to create a MSFT ticket to see if they have any further suggestions. Another thought is that if you're targeting a particular entity, or a few entities, maybe copy the default message to the CustomDisplayString for the messages you're interested in.
The question is the following:
I have a custom Requester field in TFS work items. It contains a valid TFS user name.
Is it possible to send an email to the person specified in this custom field, when the item changes a state?
In other words:
Requester = [Me]
Send email on State change
From the following questions :
1) “[Me]” variable for custom field alerts in TFS 2013
2) How to create custom Field with transition workflow in TFS
I figured out that custom fields (such as Requester) do not have = and <> operators. They have only Change, Change to, Change from. Thus it is not possible. (You can only observe the changes made to the custom fields)
Has anybody seen, herd or implemented a solution to this? Maybe a custom plug-in?
Thank You in advance!
You're looking at a server side event handler to achieve this.
Intercept the Work Item changed event
Check if the change was a
change in state
If it is, then email the address listed in the
Requester field.
There are couple of old projects on codeplex which should get you up and running but you'll need to update for TFS 2015 (and test with any updates you apply later)
Email alerts for TFS
TFS Work Item Watcher
There is a feature that just popped into VSTS that makes this a little slicker
Follow a Work Item
Although you would get notified on all changes rather than just state change
The feature was added in TFS "15" (not the same as TFS2015, see Brian Harry's blog post)
The feature is not enabled publicly yet, but there is a feature flag that you can turn on by changing a value in the team foundation registry to enable it - because it's not public yet you will have to contact Microsoft for instructions,
I have provided my email in the blog post
https://blogs.msdn.microsoft.com/rihamselim/2016/09/07/enabling-alerts-for-custom-fields-in-work-item-alerts/
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.