[AdamP]

Hi Mike

Have you tried creating the HTML string in the body of the message?

The tooltip on the body field says;

Subject and Body
This value can be a plain text or HTML. See help tab for instructions on how to use MUI.

You can use the current value from a field in the message by using the FieldInternalName in curly braces like this:
{NameOfField}
ItemLink
Use this in the Body to insert a link to the current items DispForm or EditForm:
{viewitemlink}
{edititemlink}
You can wrap it in an anchor tag like this:

<a href="{viewitemlink}">Link to item</a>

So try;

<a href="{viewitemlink}">{Title}</a>

Adam

• This reply was modified 6 years, 1 month ago by AdamP.

[AdamP]

Thanks Alexander, great support as always

[AdamP]

Have you explored the Field CSS tab in config?
https://spjsblog.com/dffs/dffs-user-manual/#Field_CSS

[AdamP]

Thanks Alexander, and well done on tracking it down.
The tab workaround works…it’s enough to just select “configure tabs” and save, no other tab setup needed.

Adam

Attachments:

1. 

   vLuFE-tab-workaround.png
   

[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 6 years, 3 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.

[Author]

Posts