[DerekH]

Alexander,
Thanks, the code worked for the number formatting, but for some reason the labels would not show up for the particular fields when editing the PreviewItem.js file (the labels all work for my other fields, just not the “currency” field).

However, I went back to using a calculated column with this formula:

=USDOLLAR([field],0) and set the configuration field type to "calculated"

It now works as I wanted, adding the dollar sign and the commas for USD. Thanks for your help with both the code and the calculated column!

[DerekH]

Okay, after carving out some time to implement this solution, here’s what I have.

Thanks Alexander and DCH for the additional comments, they were helpful. Since we primarily use IE, I changed both the variable ‘hide’ to remove and the .hide() to .remove() to keep the terms synchronized.

My thoughts: Initially, I had a hard time understanding the array (since I’m illiterate in JavaScript), but after some trial and error, I figured out what was happening: Each time I removed an item from my list, the next item would take on that array number (e.g. #4), so rather than trying to remove 4,5,6…16,17 items, I had to remove the 4th array element each time–fourteen times in a row (see below code for group “75”. Once I had this figured out, it was off to the races!

Thanks for the extremely useful solution!

function trimOptionsByGroupMembership(){
	var select = $("#dffs_Handoff"), remove = function(arr){
		$.each(arr, function(i, v) {
			$(select).find("option").eq((v-1)).remove();
		});
	}
	if(spjs.dffs.verifyGroupMembership("75")){   // CoE BA Group
		remove([3,4,4,4,4,4,4,4,4,4,4,4,4,4,4,7]);
		return;
	}
	if(spjs.dffs.verifyGroupMembership("76")){    // CoE BI Group
		remove([1,1,5,5,5,5,5,5,5,5,5,5,5,5,5,8]);
		return;
	}
	if(spjs.dffs.verifyGroupMembership("77")){    // CoE TAr Group
		remove([1,1,2,2,2,4,4,4,4,4,5,5,5,5,5,6,6]);
		return;
	}
	if(spjs.dffs.verifyGroupMembership("78")){    // CoE LM Group
		remove([1,1,2,2,2,2,13,14,14]);
		return;
	}
	if(spjs.dffs.verifyGroupMembership("79")){    // CoE TAn Group
		remove([1,1,2,2,2,4,4,4,4,4,5,5,5,5,5,6,6]);
		return;
	}
	if(spjs.dffs.verifyGroupMembership("323")){    // CoE Systems Group
		remove([1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3]);
		return;
	}
	if(spjs.dffs.verifyGroupMembership("329")){    // CoE Process Group
		remove([1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3]);
		return;
	}
}
trimOptionsByGroupMembership();

• This reply was modified 7 years ago by DerekH.
• This reply was modified 7 years ago by DerekH.

[DerekH]

Following up on this post, my issue turned out to be that when passing values from a people picker field from List A to List B (using a workflow to ‘Create Item in List B’), I was passing across the CurrentItem:CreatedBy:’Display Name’ but should have passed across the CurrentItem:CreatedBy:’User ID Number’ and then display it as ‘Display Name’ on the target List B.

Once this change was applied, the error went away and DFFS works as expected.

Thanks Alexander for the tip that got me straight on this issue.

[DerekH]

Alexander,
I’m fairly new to DFFS and I ran into the issue last week where I received “Sorry, something went wrong” when in the EditForm. I though it may be related to my OOTB EditForm.aspx since I had once customized it and subsequently deleted the XSL to get DFFS working on that list (I’ll refer to the this list as “original list”. So I rebuilt the list to make sure that wasn’t the issue.

Now that my 142 column list is completely rebuilt, I am continuing to have these issues. (I’ll refer to this list as the “rebuilt list.”)

Can you help me understand what I can do to make this work? Here are my gathered symptoms:
1. Original List has DFFS installed for DispForm and EditForm only. (Custom permissions allow for Edit and Display forms only as workflow populates this list with new items from a separate front-door list)
2. Original List is using DFFS Tabs [11 total tabs]
3. I didn’t notice any issues for the first week using DFFS, but began to have list items ‘lock up’ and would receive the ‘Sorry, something went wrong’ errors reported by my users. I deleted and recreated new records for these items on the first 3 troubles, but they continue to reappear.
4. When I Uninstall DFFS from this list, the DispForm and EditForm operate correctly.
5. URL from Original List that errors out with DFFS installed:
https://workspace.web.att.com/sites/GTOICoE/Lists/COE_MT/EditForm.aspx?ID=111&Source=https%3A%2F%2Fworkspace%2Eweb%2Eatt%2Ecom%2Fsites%2FGTOICoE%2FLists%2FCOE%5FMT%2FPersonalViews%2Easpx%3FPageView%3DPersonal%26ShowWebPart%3D%7BAD8C38B5%2D02D7%2D465C%2DB0A7%2D437D501F0544%7D&ContentTypeId=0x010030367EDAC98B2A40B0E3870663C07AC2
6. On the ‘Rebuilt List,’ with DFFS installed, I click on the defailt edit with EditForm and received ‘Sorry, something went wrong’ error with this URL:
https://workspace.web.att.com/sites/GTOICoE/Lists/ATLAS/EditForm.aspx?ID=2&Source=https%3A%2F%2Fworkspace%2Eweb%2Eatt%2Ecom%2Fsites%2FGTOICoE%2FLists%2FATLAS%2FAllItems%2Easpx
7. Tabs are not yet configured on the Rebuilt List.
8. In both ‘Original’ and ‘Rebuilt’ some records are edited and work without issue with DFFS while some give an error.
9. Once a record receives the ‘Sorry, something went wrong’ error, the record cannot be edited either with DFFS installed or uninstalled.

Hopefully I have provided enough information, but can provide more if needed.

(DFFS Frontend 4.4.2.7; CSS 4.21/4.21; jQuery 1.12.4; SPJS-Utility 1.272)

• This reply was modified 7 years, 2 months ago by DerekH. Reason: Forgot to add that some records work on both Original and Rebuilt lists

[Author]

Posts