[BenR]

Alexander,

My SP platform is SharePoint 2013 on premises.

R’grds – Ben.

[BenR]

Alexander,

I’ve captured console errors only in the attached file, comparing DFFS_v4.4.5.18 (SUCCESSFUL) to DFFS_v4.4.5.20 (FAILING)

R’grds – Ben.

[BenR]

Sooo… Alexander,

Why have you not responded to my question? It’s a pretty simple request (I think) and I don’t find sufficient information to do this on my own. Your original solution, posted in 2014, is not working.

I’ve found you highly responsive in the past – is this a sensitive subject? Frankly, I don’t ask if I know the answer – I really don’t understand, but am willing to try. I’ve learned from each answer you have provided.

Okay, if you don’t solve my problem and answer my question – at least tell me why you won’t. As I’ve stated with each time I’ve reached out for your support, I sincerely appreciate your support and efforts!

R’grds – Ben.

[BenR]

Alexander,
I hope you are well.

I am attempting a simple thing – I would like to highlight a field with background color while it is blank. My preference is not to make it a Required field, but maintain a highlight until it is populated. I’ve tried to use the top-most solution in this thread, but to no avail.

Required: While SPFieldText: CompassID is blank, change it’s background color to “#fcd4dc”. Else, if populated, leave it white.

Would this be triggered by a rule on CompassID?

As always, your support and efforts are greatly appreciated!

R’grds – Ben.
Reference:
Custom DFFS-folder: DFFS_v4.4.5.7_2020-08-30
DFFS Loader: v2
DFFS frontend: 4.4.5.7 – August 30, 2020
DFFS frontend CSS: 4.62 / 4.62
Autocomplete: 1.6.49 – June 28, 2020
Cascading dropdowns: 3.7.41 – August 30, 2020
jQuery: 1.12.4
Lookup: 1.1.20 – March 10, 2020
Resource management: 2.4.5 – August 29, 2019
SPJS-Utility: 1.348 – June 28, 2020
vLookup: 2.2.156 – June 28, 2020

• This reply was modified 4 years, 1 month ago by BenR.

[BenR]

Whoops! I embarrass myself – Err: .01% should be 1%.

[BenR]

Alexander,

I’ve gathered more statistics to judge effectiveness of my prior vs. current JS method…

Assuming that a given function will never succeed 100% of the time, grouping eight operations into one function produced a 15% failure rate across 100 invocations (one per record).

However, by breaking the eight operations into eight discrete functions each invoked once per record, the failure rate drops dramatically. The next 50 records (8×50=400 invocations) resulted in only four failures, or .01% – which is totally acceptable in my application.

Thank you for your support, I think I have a solution!

R’grds – Ben.

[BenR]

Alexander,

As my solution was to replicate the provided code eight times to address eight People Picker fields, plus the symptom is a failure of the bulk function, I’ve broken the bulk function into eight discreet functions…

I hope to see a possible improvement, and am gathering statistics.

R’grds – Ben.

[BenR]

Alexander,

I hope you are well and staying safe.

I have applied this method to retrieve additional information from eight People Picker fields (all single selection fields). I have triggered this function to On-Save rules in both NewItem and EditItem forms. However, I find that it doesn’t always work, where none of the destination fields are populated – this is in 15 of 100 sampled records.

I cannot find a pattern across the 15 failed records

• Some created via NewItem, some subsequently edited in EditItem
• Different users either create or edit failed records
• My firm uses IE, Chrome, and Firefox – but I can’t tell what my users use, but my tests show all three browsers work

Is there something in my code that you see that could cause this 15% failure rate?

function acquireRoleDetail(){
 jQuery.each(spjs.utility.getFieldValue({"fin":"Compass_x0020_Delivery_x0020_Man","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("DeliveryManagerSIP",ppData.SipAddress);
  setFieldValue("DeliveryManagerSID",ppData.Name.slice(-7).toUpperCase());
 });
 jQuery.each(spjs.utility.getFieldValue({"fin":"ExecutiveSponsor","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("ExecutiveSponsorSIP",ppData.SipAddress);
  setFieldValue("ExecutiveSponsorSID",ppData.Name.slice(-7).toUpperCase());
 });
  jQuery.each(spjs.utility.getFieldValue({"fin":"FinalApprover","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("FinalApproverSIP",ppData.SipAddress);
  setFieldValue("FinalApproverSID",ppData.Name.slice(-7).toUpperCase());
 });
  jQuery.each(spjs.utility.getFieldValue({"fin":"FinanceManager","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("FinanceManagerSIP",ppData.SipAddress);
  setFieldValue("FinanceManagerSID",ppData.Name.slice(-7).toUpperCase());
 });
  jQuery.each(spjs.utility.getFieldValue({"fin":"LegalContact","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("LegalContactSIP",ppData.SipAddress);
  setFieldValue("LegalContactSID",ppData.Name.slice(-7).toUpperCase());
 });
  jQuery.each(spjs.utility.getFieldValue({"fin":"SourcingCategoryDirector","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("SourcingCategoryDirectorSIP",ppData.SipAddress);
  setFieldValue("SourcingCategoryDirectorSID",ppData.Name.slice(-7).toUpperCase());
 });
  jQuery.each(spjs.utility.getFieldValue({"fin":"SourcingManager","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("SourcingCategoryManagerSIP",ppData.SipAddress);
  setFieldValue("SourcingCategoryManagerSID",ppData.Name.slice(-7).toUpperCase());
 });
  jQuery.each(spjs.utility.getFieldValue({"fin":"VendorManager","key":"loginName"}),function(i,login){
 var ppData = spjs.utility.userInfo(login);
  setFieldValue("VendorManagerSIP",ppData.SipAddress);
  setFieldValue("VendorManagerSID",ppData.Name.slice(-7).toUpperCase());
 });
}

As always, your support and efforts are greatly appreciated!

R’grds – Ben.
Reference:
Version information
Custom DFFS-folder: DFFS_v4.4.5.4_2020-07-04
DFFS Loader: v2
DFFS frontend: 4.4.5.4 – July 04, 2020
DFFS frontend CSS: 4.61 / 4.61
Autocomplete: 1.6.49 – June 28, 2020
Cascading dropdowns: 3.7.40 – June 1, 2020
jQuery: 1.12.4
Lookup: 1.1.20 – March 10, 2020
Resource management: 2.4.5 – August 29, 2019
SPJS-Utility: 1.348 – June 28, 2020
vLookup: 2.2.156 – June 28, 2020

[BenR]

Alexander,

Yes! SPJS-utility_v1.348 fixed my issue.

Aside from clearing the cache, I found I had to Update loader file in DFFSInstaller_V2 (… If you have updated DFFS to a new version you should hit the button to write a new timestamp to the loader file to prevent the browser from caching the script files.).

Once done, SPJS-utility_v1.348 loaded correctly, and my symptom is resolved.

Again, your support and efforts are greatly appreciated!

R’grds – Ben.

[BenR]

Alexander,

v4.4.5.0_2020-06-01 has addressed this issue.

Thank you so much for your support and efforts!

R’grds – Ben.

[BenR]

Alexander,

Further investigation… I’ve found that the symptom occurs with my Tabs configuration with the target field (ContractualPayment) placed on all three of my Tabs. To illustrate, please see attachments – one shows the symptom occurring when Tabs are selected after initial form load, and the second shows the three Tabs configuration and placement of the target field.

1. I’ve confirmed that no other rule addresses the target field
2. I’ve removed the first rule, and now only the NOT Member of Group Rule, Hide Field with allowed reversing remains
3. The symptom persists with v4.4.4.32_2020-05-10
4. The symptom DOES NOT occur with v4.4.4.23_2020-02-13
5. If I remove the target field from two of the three tabs (so it appears only on one Tab), the symptom DOES NOT occur

So, a temporary work around is to remove the target field from two of the three tabs. However, I would not consider this a fix.
As always, thank you for your support and efforts!
R’grds – Ben.

• This reply was modified 4 years, 6 months ago by BenR.

Attachments:

1. 

   1-Inconsistant-result-of-Member-of-Group-Rule.png
   

2. 

   2-Inconsistant-result-of-Member-of-Group-Rule.png
   

[BenR]

Alexander,

Sorry to have wasted your time… you are right, I was mislead by the visual clue. The styling similarity of the read-only vs. editable field, specifically with number and text fields, lead to me thinking it was a bug. Unfortunately, I feel like I wasted my own time as well.

Not to get all editorial, but I think visual clues are important to the user experience. The difference between read-only and editable could be more than if you can’t place your cursor, it must be read-only. Further, if all fields cannot be styled in a similar way when read-only (date field borders are hidden, while text, number and currency borders are displayed) the UX seems weaker. Okay, I’ll get off the soap box.

As always, I sincerely appreciate your support, efforts, and product – and truly respect your judgment (though maybe not so much this time). I’ll just add a custom CSS entry to hide the border.

R’grds – Ben.

[BenR]

Alexander,

I believe I have located the problem, and it was probably of my creation – in a previous troubleshooting session, I had hidden the SubLOB field in a rule. With v4.4.4.23, this didn’t affect the trouble LOB of my configuration, however, did in v4.4.4.26 and v4.4.4.27.

I suspect subtle timing changes in code execution between different modules/features – Rules vs. Cascade, etc.

At the end of the day, there is no action for you on this issue – it appears that v4.4.4.27 has indeed addressed my issues.

As always, I sincerely appreciate your support and efforts!

R’grds – Ben.

[BenR]

Alexander,

My testing of Rules in v4.4.4.27 shows that Rules are working as expected in reference to setting the red asterisk for mandatory fields.

However, the issue with Cascade persists, with a slightly different symptom. To recap the previous symptom:

Cascade: I have a Cascade of LOB to SubLOB. In v26, the first time one particular LOB is selected (last on list), the SubLOB field label is displayed, but the drop-down field is not displayed. If I then select another LOB, the SubLOB drop-down field is displayed correctly, and if I return to the LOB that had previously failed to display – it now displays correctly. The symptom (no display of SubLOB) occurs only on first pass.

In v.4.4.4.27, the SubLOB field label NOR the SubLOB drop-down field itself is displayed the first time this particular LOB is selected. I’ve tried a number of troubleshooting steps without success (yeah – some are silly):

• Changed the spelling of LOB so it is not at the end of the list – unsuccessful
• Deleted a number of LOB records in source list – unsuccessful
• Moved the Cascade source list to local ({currentsite} instead of /sites/blah-blah/listname) – unsuccessful
• Removed flags e.g: hide empty dropdowns – unsuccessful
• Removed rules on fields in Cascade – unsuccessful
• Removed side-by-side positioning of fields – unsuccessful
• Removed the default field value (“-select-“) – unsuccessful

Unfortunately, I have very little to relate to you in reference to this symptom – I have no idea why this particular LOB is unique in displaying the symptom.

Observations I can add:

1. If I enter the form, and select the affected LOB, it does not display the SubLOB drop-down field. If I select another LOB (which may or may not have a SubLOB value) and then return to the affected LOB, it will display normally – this is all as described before. The new bit is that after I select the default (blank) selection, the problem LOB will ALWAYS fail to display the SubLOB drop-down menu.
2. This symptom is only evident on the NewItem form, as LOB is a required field, and will always be populated when entering the EditItem form. Even if a SubLOB had not been selected when the item was saved, the SubLOB drop-down menu is displayed correctly.

Please let me know what troubleshooting I can do to better isolate the problem. I

R’grds – Ben.
Reference:
Version information
DFFS Loader: v2
DFFS frontend: 4.4.4.27 – March 21, 2020
DFFS frontend CSS: 4.57 / 4.57
Autocomplete: 1.6.47 – March 10, 2020
Cascading dropdowns: 3.7.36 – March 21, 2020
jQuery: 1.12.4
Lookup: 1.1.20 – March 10, 2020
Resource management: 2.4.5 – August 29, 2019
SPJS-Utility: 1.345 – March 17, 2020
vLookup: 2.2.148 – March 17, 2020

• This reply was modified 4 years, 9 months ago by BenR.

Attachments:

1. 

   Step-1-Cascade-launch-NewItem-DFFS_v4.4.4.27.png
   

2. 

   Step-2-Cascade-select-troublesome-LOB-DFFS_v4.4.4.27.png
   

3. 

   Step-3-Cascade-select-another-LOB-DFFS_v4.4.4.27.png
   

4. 

   Step-4-Cascade-return-to-troublesome-LOB-DFFS_v4.4.4.27.png
   

[BenR]

Alexander,

Nicely done! Thank you so much for your support and efforts!

R’grds – Ben.

[Author]

Posts