BenR

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 30 total)
  • Author
    Posts
  • 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 1 month 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 3 months, 1 week 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.

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

    Alexander,

    Yes – I believe your suggested Callback function will do the trick… However, I do need additional guidance.

    I have created an additional field, TemporarySubLOB, to capture the AutoComplete Tier-2:SubLOB value via setFields. When the Tier-2:SubLOB field is ready, I would like to move the value of TemporarySubLOB to it.

    
    
    // Set value to Cascade to address timing of Tier-2 (SubLOB)
    function spjs_casc_ready(id, readyFIN, index) {
        var config = spjs.casc.data[id];
        var filterValue = getFieldValue(config.thisListFields[(index - 1) > - 1 ? (index - 1) : index]);
        // Add your custom code here - like this example
        if (readyFIN === "SubLOB") {
            setFieldValue("SubLOB", "TemporarySubLOB");
        }
    };

    Do I just add the suggested function to Custom JS, or do I have to invoke it from a Rule? If I invoke it from a Rule, what parameters do I pass? I don’t see a id or index value in the Cascade debug information.

    As always, I really appreciate your support and efforts!

    R’grds – Ben.

    in reply to: Autocomplete, Sort, Source List Over 1,000… #27311
    BenR
    Participant

    Alexander,

    I’m sorry to say that my analysis of the problem was false… As I continue to test, I’ve found that the number of items in the source list is not the cause of the problem (just a difference between my DEV to PROD environments) – sorry for the false lead.

    The problem is with the result sorting the ID field (which is a number field) is not following numerical sort (sample result: 100, 150, 2, 25, 3, 55, 550).

    Reading about SPJS-Lookup, you address this symptom in the customSort option, describing: “… This sort function example sorts values that contains numbered options from 1-10. The default alphabetical sort order would sort like this: 1, 10, 2, 3 etc., but now it will show 1, 2, 3 …”

    Is a numerical sort possible in Autocomplete?

    Again, sorry for the false lead.

    R’grds – Ben.

    in reply to: Tooltip sizing post 4.4.4.4 #26659
    BenR
    Participant

    Alexander,

    This correction in v4.4.4.5 has addressed this issue nicely!

    I found that I did not need to use the width override at all – your default method of width calculation worked quite well for my Tooltips throughout my forms (both short and long, multiline Tooltips).

    As always, your support and efforts are appreciated!

    R’grds – Ben.
    P.S.: I’ve now upgraded to v4.4.4.5 in production!

    in reply to: Rules: Set field value post 4.4.4.0 thru 4.4.4.2 #26526
    BenR
    Participant

    Alexander,

    I’ve tested with DFFS_v4.4.4.4_2019-07-08 released today…

    My symptom was caused by Rule execution order, and v4.4.4.4 does remove the symptom.

    The Rule execution order does not match v4.4.3.65, where it appeared that rule order simply followed index number 1,2,3,4. It appears that in v4.4.4.n, rule order seems to be FALSE ascending then TRUE ascending – but this is my unfounded guess. (Screen shots follow comparing two versions…)

    At the end of the day, this symptom is resolved! As always, thank you for your support and efforts!

    R’grds – Ben.

    in reply to: Rules: Set field value post 4.4.4.0 thru 4.4.4.2 #26489
    BenR
    Participant

    Alexander,

    The field that displays the symptom is [Commodity Type]. This field is cleared in Rule-1, and set in Rule-3. However, Rules-1,-2,-3,and -4 are triggered on a different field called [LOB].

    Full Rules screen captures follow.

    R’grds – Ben.

    in reply to: Rules: Set field value post 4.4.4.0 thru 4.4.4.2 #26480
    BenR
    Participant

    Alexander,

    Could the fact that the trigger field is the first-tier of a two-tier cascading dropdown contribute to this issue?

    R’grds – Ben.

    • This reply was modified 11 months ago by BenR.
Viewing 15 posts - 1 through 15 (of 30 total)