[AdamP]

Hi Alexander

The single file substitution works – 2.2.105 into the latest package results in a functional vLookup.
Substituting 2.2.108 also works.
It seems to be the move to 2.2.116 in the 2018-01-21 package that causes it to fail for me.

Adam

Attachments:

1. 

   vLuFE2-2-105-on-20180731package.png
   

[AdamP]

Hi Charlene.

I think this sounds like the same issue I’m currently encountering.
Have a look at this thread
Adam

• This reply was modified 5 years, 7 months ago by AdamP. Reason: Corrected link

[AdamP]

I’ve only used this snippet a couple of times, but I don’t think you need to call it in a rule on save, dffs_PreSaveAction() knows to run when the form is saved. Just add it to custom JS.

Adam

[AdamP]

If you save the child form does it retain the prefilled value in the year field?
Your config has the tick box for hide field ticked…my understanding is that hides the field on the child form, so the value is prefilled, and can’t be changed by end users.
If you untick it what happens?

[AdamP]

Latest Package (non-working);

spjs.vLookup.version;
“2.2.123”
spjs.vLookup.init();
undefined

Latest package modified with December 2017 SPJS-vLookup_frontend.js (working);

spjs.vLookup.version;
“2.2.108”
spjs.vLookup.init();
undefined

In both cases nothing seems to change after the init. The Latest version continues to show the /_layouts/images/gears_anv4.gif spinner and “Loading…” text.

[AdamP]

It seems I created a red herring in my initial assessment of this issue, I think there were some browser cache settings interfering.
The issue for us actually seems to lie in SPJS-vLookup_frontend.js.

I can install the very latest package of DFFS in it’s entirety and vlookup fails as per the original screenshot. If I then replace /SPJS/DFFS/plugins/SPJS-vLookup_frontend.js with the version from the 2017-12-20 package, vlookup fields immediately start to work correctly again.

Running firefox developer tools > network tab on an identical form, I get the following results consistently;
2017-12-20 vLookup_frontend: 73 requests, 4,045.71kB, 8.01s
2018-01-21 vLookup_frontend: 67 requests, 4,029.43kB, 7.52s

The 6 requests difference are the ones shown in the screenshot attached (using vlookup_frontend 2017-12-20), but with the later vlookup_frontend, they just don’t appear to fire at all.
Clicking the vLookup refresh button using vLookup_frontend 2017-12-20 returns the last 4 rows from the screenshot.

Is anyone else successfully running SharePoint 2010 and a vlookup version after 20th December 2017?

Thanks

Adam

Attachments:

1. 

   vLookupFrontend20171220.png
   

[AdamP]

Double check your field names – they should be the internal names, not the display names (see the fields tab in DFFS config and copy/paste for best results).
In SP2010 the internal names for start time and end time in calendars aren’t entirely logical;
EventDate for start time, so use {EventDate}
EndDate for end time, so use {EndDate}

I don’t know if that holds true for later versions of SharePoint, but it’s a good place to start looking.

Adam

[AdamP]

All seems to be working correctly (incl in IE8 mode) in the latest version.
Thanks Alexander!

[AdamP]

I think I’ve spotted another slight bug with this, even in firefox.
If you select a list with a custom DFFS version installed, the installer reports the correct folder in the custom version field.
If you then switch to a different list using the “Target list:” dropdown, if there is no custom version installed then custom version field incorrectly reports the folder (it shows the value from the previously selected list with custom version installed)
The custom version field seems to only update correctly if a custom version is actually installed on the target list – which could lead to confusion.

[AdamP]

Yes – the whole package was updated – SPJS/DFFS folder replaced with entire package from the download. When we noticed the problem I started experimenting with the custom versions to track down the issue.

I can force it to fail by switching from DFFSv2017-12-20 to DFFSv2018-01-21. Then replacing DFFS_loader.html from 2017-12-20 into the 2018-01-21 version appears to restore the vlookup functionality, although ace.js doesn’t actually exist on the path specified in the older loader…

Firefox behaves exactly the same as IE11 (in IE8 mode), changing the document mode in IE has no effect.

Attachments:

1. 

   ACEsrc-min-noconflict.png
   

2. 

   ACEDecember2017.png
   

3. 

   DFFSVersions.png
   

[AdamP]

Actually, if I let the debugger run, I end up with three of the same error in the console – presumably one for each form.

[AdamP]

Thanks for your quick reply Alexander.

The config loading doesn’t continue any further, but I think I’ve worked out what’s happening…

I’m on SP2010 so the document mode is set to IE8. If I use developer tools to change that to IE9 or above the installer page loads correctly with the custom version field populated. Firefox also okay as it ignores the IE document mode…

With IE8 mode active there is an error in the console when I select the list to install/reinstall;

SCRIPT5007: Unable to get property ‘match’ of undefined or null reference
File: DFFS_Installer.aspx, Line: 1247, Column: 75

That line is;

var rw = jQuery(data).find(“Content”).html(), ra = rw.match(/\/\*dffs_loader_custom_code\*\/(.*?)\/\*dffs_loader_custom_code\*\//), rf = rw.match(/dffs_custom_version_folder=\”([^’]*?)\”/);

Unable to get property ‘match’ of undefined or null reference

Now I know how to work around it it’s not a huge issue, but might catch some people out.

Adam

[AdamP]

Thanks Alexander

The code above – is that different to the built in functionality in the Misc tab of DFFS?

Enter setup button
Disable the “Enter setup” link on the “Enhanced with DFFS” text below the form for all but these user IDs or SharePoint group names / IDs. Use with caution – I recommend setting a password instead.

There is also the option to allow access to the backend config via a dedicated page – That could be set up in a separate site pages library to limit access to authorised users (in conjunction with removal of the setup link on the form)

While I wouldn’t normally support any form of item level permissions, in this case it might be quite effective if used on dffs_backend_min.js

Adam

[AdamP]

I’d actually prefer to see more support for permissions based access and avoid passwords altogether. That gets away from the issues surrounding forgetting/sharing of passwords.
I usually rely on permissions on the SPJS-DynamicFormsForSharePoint list – so users may be able to get in and view the config if they know to click bottom left on the form, but they can’t do any damage as they only have read access.
Would it be possible to apply restrictive permissions to dffs_backend_min.js so that only authorised users can access/view the backend config?

[AdamP]

So you have a separate list which has a mapping of users to approvers?
You want to load a form, and depending on who the user is, determine who the relevant approver should be?

[Author]

Posts