Office 365 Update Changes ‘Display Name’ on Required Fields

73 Comments

1. Yesterday we discovered that the same thing had happened on one of the SharePoint 2010 on premises environments we are working with. We were informed from operations team that a CU(i think it was December) had been installed the day before.

   Reply

2. I’ve added a few updates to the post. I’m getting some reports that this issue is popping up in SharePoint 2010 installations when the December CU is applied, though it may also be in SP2. More as I find things out…

   Reply
3. Pingback: Changes to Required Field ‘title’ Attribute in SharePoint?!??!? |

4. Fine, here’s my two cents. It sucks. This has been consistent for as long as I can remember with a thousand blog posts referencing the method of using the title attribute, if Microsoft had been paying attention or cared about the developers this would have been addressed differently.

   That being said, I did throw together the following function for getting a field based upon those internal comments that use the internal field name and field type. I’m not crazy about it from a performance standpoint, and what’s to stop Microsoft from changing the way they do the comments? It’s currently only for Text Fields and lookups, but you get the gist.

   	function GetField(internalFieldName)
   	{
   		var fieldElement = undefined;
   		var container = undefined;
   		var fieldType = undefined;
   		
   		 $("table.ms-formtable td").each(function(){
               if (this.innerHTML.indexOf('FieldInternalName="'+internalFieldName+'"') != -1){
                   container = this;
                   //I don't like this method for getting FieldType, there's gotta be a better way
                   fieldType = container.innerHTML.split('FieldType="')[1].split('"')[0];
                   //break out of each loop
                   return false;
               }
           });
           
           switch(fieldType)
           {
           	case "SPFieldText":
           		fieldElement = $(container).find("input[type='text']");
           		break;
           	case "SPFieldLookup":
           		fieldElement = $(container).find("select");
           		break;
           	default:
           		break;
           }
           
           return fieldElement;
   	}
   

   Reply

   1. Mark:

      Yeah, I’ve used the comment field in places where I’ve had to, like with radio buttons and checkboxes where there’s simply *nothing* else that I can use. It’s sort of my last resort because I don’t trust it, either. On the other hand, I’ve been trusting the title attribute for over 8 years, and look where that’s gotten us.

      I’m heading toward something more like this, though this doesn’t work for non-English instances:

              if (((this.Obj = $("select[Title='" + colName + "']")).length === 1) || ((this.Obj = $("select[Title='" + colName + " Required Field']")).length === 1)) {
      

      At least in this case, they seem to have been consistent with the translations (as noted in my update to the post above today). In the multi-selects, the translations are all over the place, as I noted in my post From SharePoint Magazine: Variations in Multiselect Controls in Different SharePoint Language Versions.
      M.

      Reply

5. I have been scratching my head for about a month – my cascading dropdowns were no longer working and I did not have a clue why. So, the mystery is now understood. But how to deal with it…

   It turns out that both of my dropdown columns are required. No cascading occurred when I added “Required Field” to both the parent and child column Display Names. It worked as expected when both columns were changed to “not required”.

   I needed the cascade function and required values so I stiched them together using jQuery like this:

   $(document).ready(function() {
   	// Set up the cascade Main_Category to Sub_Category
   	$().SPServices.SPCascadeDropdowns({
   		relationshipList: "Main_Sub",
   		relationshipListParentColumn: "Main",
   		relationshipListChildColumn: "Title",
   		parentColumn: "Main_Category",
   		childColumn: "Sub_Category"
   	});
   });
   function PreSaveAction(){ 
      var main_val = $(":input[title='Main_Category']").val();
      var sub_val = $(":input[title='Sub_Category']").val();
   //if a choice has not been made in a list, the value is zero
      if(main_val == 0){
        alert("Warning: Select value for Main_Category!");
        return false; 
      }
      if(sub_val == 0){
        alert("Warning: Select value for Sub_Category!");
        return false; 
      }
      return true;
   }   
   

   I learned that SharePoint provides the PreSaveAction function that allows me to add custom code that runs when you Save your list. The function above checks to make sure each column has a valid choice or halts the save with a warning message.

   By the way, I noticed quite a few bloggers recommend using SharePoint Designer to add the code directly to the new or edit form. It is much easier to link the code in a .js file to a Content Editor web part that is easily added in the client by editing the new or edit form web parts.

   I eagerly await a more elegant solution.

   I really appreciate the information and time that folks like you and that HillBilly guy (I used his parent-child list model) provide this community. I hope this helps others..

   By the way, I’m also a knowledge management zealot.

   Reply

   1. jstemke:

      Great band-aiding. I’m curious what version of SharePoint you’re on if you’ve been having problems for a month or so. Are you on premises or on Office365? What CU or version level?

      Watch for an imminent new alpha of 2014.01 with fixes for this stuff.

      M.

      Reply

      1. Marc: I’m using SharePoint online, version: 16.0.0.1205

         Reply

6. Hi Mark. To avoid duplication in the title selectors, you could leave the space in the literal:
   [Title^=”Region “], but if they change the UI back after the next service pack, we are again screwed. I’ve fought these kinds of API issues for years. This is the first I’ve seen in SharePoint. I hope it isn’t a trend.

   Reply

   1. Dan:

      Unfortunately, it’s more complicated. Since we could have a column called “Region 2″, the selectors need to be more solid. I think I’ve got a reasonable fix for 2013 /Office365 using regex on the select’s id. I’m trying to get an example from a SharePoint 2010 installation where the December CU has been applied, as I’ve gotten reports of the same ” Required Field” stuff there as well.

      Oh, and there’s another added wrinkle: the ” Required Field” test is localized with other language packs.

      M.

      Reply

7. Another option for those looking for a quick hack to get their old scripts working again,
   In your document.ready place the following script at the beginning. It will find all the title attributes with ” Required Field” and remove that text from the attribute, your old script should work fine now. Is it a hack? Absolutely. Will it get your forms working quickly until you can think of something better?? Yes… As long as the name of your field isn’t SUPPOSED to have ” Required Field” in t.

   $(“[title$=’ Required Field’]”).each(function()
   {
   $(this).attr(“title”,$(this).attr(“title”).replace(” Required Field”,””))
   });

   Reply

   1. This hack makes me nervous Mark, but yep, it’ll work. I’ve already got a fix for Office365 / SharePoint 2013 that I think is bulletproof using regex on the id.

      If anyone here has seen this issue with SharePoint 2010 (with or without the December 2013 CU) and can send me the resulting markup, I’d appreciate it.

      M.

      Reply

      1. More nervous than what MS is already doing? :) It will at least get your scripts functioning again without having to touch any of your existing scripts.. then you can go back and factor in a better solution.

         Reply

         1. I’ve found that when people do stuff like this, it’ll be there in two years. Only do it if you are going to fix it.

            M.

            Reply

         2. Mark, the main risk here is that while fixing your own script you might break something else (why did MS feel the need to change it?). Rather than modifying the existing attribute, you’re better off storing the resulting value in a different attribute.

            I’ll add that people will also need to learn not to use “document ready” anymore, as it doesn’t mean much with asynchronous SharePoint pages.

            Reply

            1. One other note on the hack: the ” Required Field” text is localized, so you’d need to adapt the hack to your own language if it’s not English.

               Reply

8. Hey.. you can either be problem solvers or problem finders. :) I stand by my statement that people experiencing broken functionality can put my script in place (changing the language where necessary) and use it until they can figure the correct path going forward… sheesh.. :)

   The title attribute is not required (at this time) for postback and does not appear to impact SharePoint native functionality.

   Reply
9. Pingback: Regex Selector for jQuery by James Padolsey FTW | Marc D Anderson's Blog
10. Pingback: SharePoint Apps Playbook Series: Part 4 – ‘In SharePoint’ | Jeremy Thake's musings

This site uses Akismet to reduce spam. Learn how your comment data is processed.