[Colin]

Hi Alexander,

I forgot to circle back with you on this one. The changes worked perfectly. We are good to go now.

Much appreciated,
Colin

[Colin]

Hi Alexander,

Thanks for looking into this so quickly.

I for one think the {{}} option would be best as it preserves the {} for backwards compatibility, and allows for an update that does not require any changes to configuration.

If there ends up being a beta for the next release please let me know. We are eager to get the latest update in place as it resolves the e-mail ID issue that we identified.

Once again thank you for your great support and software!

Colin

[Colin]

HTML for one of the sections (scrubbed URL):

<div style=”padding: 10px 10px; margin-left: 80px “;><input type=”button” value=”View Documents” onclick= myOpenInDlgFunc(‘https://abc.com/Effort/Forms/AllItems.aspx?FilterField1=Effort_x003a_ID&FilterValue1={ID}’) ;return false;”></div>

[Colin]

Here is the function:

function myOpenInDlgFunc(url){OpenPopUpPage(url,function(result){if(result === 1){
// dialog is closed with OK
}else{
// dialog is closed with X or cancel
}});}

[Colin]

Other image attached.

Attachments:

1. 

   dffs1.png
   

[Colin]

Images attached.

Attachments:

1. 

   dffs2.png
   

[Colin]

Hi Alexander,

Thank you for the quick response.

The reference was used in Tabs in a “Add HTML section” within “Visible fields and headings”.

Colin

[Colin]

We ran into issues with the latest version as well. We ended up reverting to restore functionality to our users. The issue we discovered before reverting was that bracket references (ex. {id}) were returning HTML span tags that included the expected value. The HTML qoutes caused early termination of DFFS functions and downstream issues from there. Do you suspect our issues are caused by the same jQuery version mismatch? When we upgrade we archive the entire DFFS folder from our site root and load in the the latest folders/files from the zip.

SharePoint 2013 On-Prem – JSLink

[Colin]

Great! Thank you Alexander.

[Colin]

Makes sense. Maybe there is relation to that then for some of the affected users… Within our group of affected users, the users with two user accounts (matching e-mails in both) have one account that starts with “n” and another that does not. We want to send the e-mail to the account that does NOT start with “n”. I wonder if the “n” in the other account is creating conflict somehow.

We still have the rest of the affected users, without two accounts and without an “n” start where using LoginName resolved the no send issue. That leads me to believe the “n” isn’t the only cause but may be one to explore as well.

Thank you for your ongoing support,
Colin

[Colin]

They do not, but you do have me curious as to what bug that may cause? 🙂

Of the users that were not getting e-mails we have been able to identify one of two or more causes. A subset of that subset of users have multiple Active Directory accounts with the same e-mail assigned to both. We believe this causes an issue on the SharePoint Server side when validating the user as it receives multiple accounts when expecting one, and gives up there. We are still looking to understand what the root is for the rest of the users but the solution I mentioned in my last comment does solve the problem for all users, as well as works as expected for the users that worked using only email. Seeing the REST Email API provided with SharePoint is documented to accept a UserID in the To/From/CC variable would it be better to use that at all times given it is unique where e-mail may not be?

[Colin]

Thanks for the additional information Alexander!

My team and I are trying to avoid using workflows where possible. The REST approach has been working well for us in 98% of cases but we came across a few users where e-mails were not going through. However, e-mails generated from SharePoint alerts, permission grants, and powershell were going through without issue . We eventually discovered this SE post (http://sharepoint.stackexchange.com/questions/167348/sp-utilities-utility-sendemail-to-must-be-different-format-for-some-users) which found the resolution to be passing the users LoginName with an extra \ added to it (ex. i:0#.w|domain\\username). We have tested this and found it to resolve the issue.

Would it be possible to update DFFS to use the LoginName from the PeoplePicker Values or provide an option for the user to choose this?

[Colin]

Thanks for sharing! Would it be possible to have this added into DFFS?

[Colin]

Refreshing would be fine (and expected in most cases I think). The end goal would be for the user to end up back at the same spot. At the moment the form closes and the user has to click back into the item.

[Colin]

Would it be possible to get this redirect and save without close functionality built into the configuration forms?

[Author]

Posts