BenR

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 36 total)
  • Author
    Posts
  • in reply to: Conditional Highlighting #32108
    BenR
    Participant

    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.

    in reply to: Conditional Highlighting #31911
    BenR
    Participant

    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 2 months, 3 weeks ago by BenR.
    in reply to: Pull user info from a people picker #31291
    BenR
    Participant

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

    in reply to: Pull user info from a people picker #31289
    BenR
    Participant

    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.

    in reply to: Pull user info from a people picker #31236
    BenR
    Participant

    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.

    in reply to: Pull user info from a people picker #31232
    BenR
    Participant

    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

    in reply to: Rules issues introduced DFFS_v4.4.5.0_2020-06-01… #30513
    BenR
    Participant

    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.

    in reply to: Inconsistant result of Member of Group Rule… #30399
    BenR
    Participant

    Alexander,

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

    Thank you so much for your support and efforts!

    R’grds – Ben.

    in reply to: Inconsistant result of Member of Group Rule… #30352
    BenR
    Participant

    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 7 months, 3 weeks ago by BenR.
    in reply to: Rules issues introduced DFFS_v4.4.4.28_2020-03-17… #29345
    BenR
    Participant

    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.

    in reply to: Rules issues introduced DFFS_v4.4.4.26_2020-03-17… #29239
    BenR
    Participant

    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.

    in reply to: Rules issues introduced DFFS_v4.4.4.26_2020-03-17… #29227
    BenR
    Participant

    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 9 months, 4 weeks ago by BenR.
    in reply to: Autocomplete setFields SPFieldUser #27474
    BenR
    Participant

    Alexander,

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

    R’grds – Ben.

    in reply to: Autocomplete setFields SPFieldMultiChoice #27419
    BenR
    Participant

    Alexander,

    Most excellent! This worked, and a good lesson taught!

    As always, thank you for your support and efforts!

    R’grds – Ben.

    in reply to: Timing issue: Autocomplete vs. Cascade #27376
    BenR
    Participant

    Alexander,

    Oh duh! Your suggestion took very little to get working – though my poor scripting skills slowed me down.

    The solution as you suggested worked perfectly! Thank you so much!

    R’grds – Ben.

Viewing 15 posts - 1 through 15 (of 36 total)