Search Results for 'list form'

[Amal Vellappillil]

Hi Alex, I just updated from 1.0.83 to 1.1.x. I understand that opening records in a panel is not possible at the moment. However, have you noticed records opening up much slower than when it was opening in a panel?

Before, when I had to link to a record, we used https://…./allitems.aspx?DFFSID=123&DFFSForm=disp . I have followed this convention in many rules and also in some of our custom web parts. Is this still the way to link to an item? I noticed the URL changes to something completely unrelated to the list when opening any form. What is the recommended way?

On a side note – If you have DFFS enabled in a list, how do you restore a version from the version history? I am able to see the version history panel. But no option to restore a particular version.

For now i have reverted back to 1.0.83 until i get some clarity on the URL. Version issue is happening in 1.0.83. I didnt check in 1.1.x.

Thank you for your help.
Amal Vellappillil

[Jonathan Stamper]

Alex, been a long time and I hope you’re doing well. I’m having an issue that may correlate to the dreaded “&” on our subsite not being encoded correctly to %26 on my browser. DFFS works fine on other lists, but when I try to install it to a new list on that subsite, I don’t get a button but instead get “URL is not for this web.” I notice, that if I switch the site base url out of the subsite with the “&” to the parent site, I don’t have issues installing to a list. As a heads up, we have recently updated to a new version of SP SE but only using Classic pages, but I don’t think that’s an issue. I wanted to get your take and see if you have any suggestions. I’m currently Classic DFFS from 8/12/2024.

Attachments:

1. 

   subsite-with-.png
   

2. 

   Another-subsite-same-parent-but-no-in-name.png
   

[Wayne Thompson]

Hi Alexander! 🙂

Display form items that had vLookup Add new item enabled now longer render and are not shown on the form since the update. I entered the DFFS configuration for all of the forms for each list (parent and child) and used the new “Install DFFS” tab to activate Modern DFFS as the default form for each form in the lists.

Thanks,
Wayne

[Alexander Bautz]

Hi,
You must not run this line:

$(“input[id$=diidIOSaveItem]:last”).click();

until after your custom sendMail is completed to ensure the form is not closed before your email is sent.

I don´t see any reason the txtRequestStatus field would not be set though – are you sure it is not overwritten by for example a FLOW? – do you see the value in the version log of the list item?

Alexander

[SteveE]

Hey Travis,

Obviously I’m not Alex but I thought I’d chime in. I’ve done very similar things and I do think clearing the values upon change of request type is probably the best approach. Whether you group the fields in tabs is just a design choice to make, but the building out of the fields to display and require can all be done using one list and one form.

My personal opinion is that writing some custom JS is probably going to help you make some of this easier. Rules are awesome, but sometimes when you start getting fairly complex, writing something custom can be a better way to handle some things. I think of it like SharePoint itself: it’s great on its own doing some basic stuff, but once you get more and more complex, a different approach is necessary. That’s how you got to using Alex’s work!

I would probably think about what you have that is causing the biggest issue and how rules may not be handling it and address those in some custom code. Is it that the request type changes and fields aren’t visible and/or required? Try making a code block that will handle that as a switch statement. If it’s only certain fields maybe only those need to be included. Something like

switch (requesttypecolumn.value){
case “email”:
columnname1.value=””;
columnname2.value=””;
break;
case “network”:
columnname3.value=””;
columnname4.value=””;
break;
};

In addition to setting values you could make things required, visible, or whatever else you want. But that way at least the main issue you are having is handled and you can use rules for the more “basic” things you are doing. Obviously my code there isn’t calling your fields or their values correctly, but I thought it might help you in your design planning.

Just my opinion so feel free to disregard.

– Steve

[Travis Goodman]

Hey Alex, looking for your input/opinion on best practices for when I have a setup that would have multiple forms all in one list.

Example: I use SharePoint lists and DFFS very often to create a ticketing system for various teams. The first dropdown in almost every one of these forms is for “Request Type”. A team could have 10+ different choices to choose from for Request Type, and based on the choice, I want to present them with very different fields to fill out. Some of these fields apply to more than one request type, which is a key detail in why I’m making these posts.

Knowing this, what kind of a setup do you recommend as a best practice, because I’m quickly finding out that the way I’m doing it is resulting in a lot of rule conflict logic (I have one list that has over 80 rules on one of the forms!)

Should I separate these forms into Content Types and add the fields that cross over into multiple different request types into each content type?

Should I separate the request types and the fields into tabs in DFFS?

What are your thoughts here? The biggest issue I notice is someone will select a request type, start filling it out, and then realize that’s not the form they wanted, so they’ll change the request type to something else which triggers different rules. Well, now in some cases they are causing rule conflicts, specifically when they set a value of a field and I had a requirement set on another field when that value is set and then when they change request type, those fields aren’t even visible, they have no value, now the person can’t even save. Headache, and it’s all because of my own setup. I need to optimize it.

Interested in your thoughts, ultimately this is a “me” issue for me to resolve. One thing that could help me out is if there is a DFFS function I could leverage in Custom JS that when they change the request type, it clears out every field they might have modified, and basically resets the form, but that might not be the truly best way to go about this.

I could also just set the request type to read-only once they pick something, then they have to refresh if they chose the wrong one. Not the best user experience though, but it’ll stop this issue.

[Amal Vellappillil]

Hi Alex,

I have a requirement in which i need to create a new record in a different list (lets call it LIST-B) from LIST-A. My current rule setup is as follows in LIST-A:
Rule-A
Trigger based on field change. Checks if a particular field is “Yes” and is changed from initial value. If true, then the action is to prepare an email and then call a function that flags a variable (VARIABLE-A) to true.

In my dffs_PreSaveAction, i am checking if VARIABLE-A == true and if it is then call a function to create the new record in LIST-B with some data from LIST-A. This function is an async function. So i am using the .then().catch() pattern. Depending on the response from the record creating function, i am either returning true, or false (to stop saving). However, no matter what I do inside the then() or catch(), I am not able to stop the form from saving. I am guessing this is due to the new record creating function is async. If that is the case, what are my options to achieve my requirements?

My new record creation function also sets a global variable (newRecordUrl). This is the url of the newly created record. Will setting the variable here work, if the “prepare email” action is using the [[variable:newRecordUrl]] in Rule-A? If this is not possible, what are my options for such requirements?

Greatly appreciate all your help.
Thank you!

[Jon Whisman]

Hello all – have a weird one. We’ve had an issue a couple times in the past few months where a user fills out the form, does a save, DFFS sends the email but no actual record was created.

I have my DFFS sending occurring in the Preave action. Maybe this is a mistake. My hunch is that some error is occurring in PreSave that I’m not seeing, but DFFS still sends the email. Due to the un-seen error though, the record is not saved – even though the user thinks it did.

If any of that makes sense, has anyone else had similar issues? Any tips or canned code for error logging I can implement in my presave that any aware of?

Ideally, I want to return out of my presave and NOT send any DFFS email if any error is logged.

Thanks in advance!

[Amal Vellappillil]

Thank you for the tip on _DFFSID column.

I know this is not possible now, but do you think in the future we can have something like this.
– Setup a rule with all the emails that need to be scheduled (the ones with the same delivery date). This would just be a place holder for a function to get information from later.
– Then from another rule (that calls a js function), refer to this rule and loop over the emails and get its to, bcc, cc, subject, body values.
– Then using custom js function add it to the custom list that is used to scheduling email. (This part I am already doing)

I am just looking to see if we can avoid having to construct the emails from within javascript as supposed to having it setup using a rule which can greatly help with maintaining it down the road.

[Alexander Bautz]

You can use the DFFSID (you must add a field with internalname _DFFSID your list and the DFFSID will be autogenerated) like this from an email triggering on any trigger you like:

Here is the new item: <a href="https://contoso.sharepoint.com/sites/YourSite/Lists/YourList?DFFSForm=disp&DFFSID=[[fieldValue:_DFFSID]]">Link</a>

Scheduling emails is not possible directly from DFFSS. You must use a FLOW to achieve this (by adding a send-date field in your list item and using a FLOW that runs on a schedule every day looking from send-date match in the list).

Alexander

• This reply was modified 5 months, 3 weeks ago by Alexander Bautz. Reason: Fixed link-format

[Amal Vellappillil]

Hi,

I have a requirement to send email from New form with the link to the newly created record. Here is what I tried so far:
– Use a rule that uses after form is saved trigger.
– Call a function from that rule.
– Inside the function construct the email with the link to newly created record.
– Create a separate list (which i had created earlier to make scheduled emails work).
– Create a new record in that list.
– I have aMicrosoft flow that runs periodically that picks up records from this list that hasnt been processed completely. If it needs to be sent now, it will send now and update the record as sent. If it needs to be sent on a later date, it skips it.

Creating email from within a Javascript seems tedious and harder to maintain. Its pretty much impossible for those who are not developers to update this email on a later date. Is there any other solution that you can think of or recommend that can ease this process and make maintaining such rules not hard?

The same question goes for scheduled emails as well.

Thank you,
Amal Vellappillil

[AdamP]

Hi Alexander

We previously had issues with modern DFFS not displaying the dffs forms for a list: https://spjsblog.com/forums/topic/modern-dffs-not-loading-for-some-users-listbasetemplate/ which I thought I’d replied to to say all working again, but I can’t see a final post (apologies if I didn’t follow up after your fix !)

Today we’ve had reports come in that the embedded list view is misbehaving again, and there is a similar but different error triggered in the console as soon as the item is clicked (standard SharePoint form is displayed):
dffs-command-set_7a9ba9f4a29d2d88fc7f.js:246 Uncaught TypeError: Cannot read properties of null (reading ‘closest’)
at t.getCurrentListContextOnClick (dffs-command-set_7a9ba9f4a29d2d88fc7f.js:246:2403220)
at t.viewOrEditItem_newUI (dffs-command-set_7a9ba9f4a29d2d88fc7f.js:246:2394991)
at dffs-command-set_7a9ba9f4a29d2d88fc7f.js:246:2412388
at HTMLBodyElement.<anonymous> (dffs-command-set_7a9ba9f4a29d2d88fc7f.js:246:2407521)

We were running v1.0.68.0 and have upgraded to v1.0.73.0 in case anything has been fixed in the interim, but the error in the console is the same. I’ve advised end users to access the list directly where it’s working normally. Any idea if this is fixable or would it be best to avoid embedded lists for the moment?

Thanks

Adam

Attachments:

1. 

   ModernDFFS-closest.png
   

[Rad]

I got it from -> https://spjsblog.com/2017/08/19/dffs-example-training-application-list-with-approval/

but here’s the CSS:

.statusBannerIcon{
display:inline-block;
font-size:35px;
margin:5px;
color:#cccccc;
}
.approvalWfLabel{
font-size:18px;
font-weight:bold;
border-bottom:1px silver solid;
padding:0 0 10px 5px;
}
.customHeading{
background-color: #1B619B;
color: #EFF2F6;
font-size:16px;
padding:5px 10px;
}

Below Function being called from “Click function name” within the tab:

//create Status numbers on top of the form
function showApprovalStatus(){
var b = [], label, labelColor, status, spjsStatusArr = [
{“label”:”New”,”icon”:”①”,”color”:”#0000FF”},
{“label”:”Draft”,”icon”:”②”,”color”:”#1E90FF”},
{“label”:”Cancelled”,”icon”:”③”,”color”:”#FFD700″},
{“label”:”Submitted”,”icon”:”④”,”color”:”#3CB371″},
{“label”:”Returned”,”icon”:”⑤”,”color”:”#e81123″},
{“label”:”Review”,”icon”:”⑥”,”color”:”#0000FF”},
{“label”:”Approved”,”icon”:”⑦”,”color”:”#107c10″}
];
status = getFieldValue(“txtRequestStatus”);
jQuery.each(spjsStatusArr,function(i,c){
b.push(“<div title='”+c.label+”‘ class=’statusBannerIcon'”);
if(status === c.label){
b.push(” style=’color:”+c.color+”‘”);
label = c.label;
currStatusIndex = i;
labelColor = c.color;
}
b.push(“‘>”+c.icon+”</div>”);
});
jQuery(“.approvalWfStatus”).html(b.join(“”));
jQuery(“.approvalWfLabel”).html(“<span style=’color:”+labelColor+”‘>Current status: “+label+”</span>”);
}
setTimeout(function(){
showApprovalStatus();
},500);

Attachments:

1. 

   Capture1.png
   

[Travis Goodman]

I solved for the timezone issue by adding a Customizer function to the field in the vlookup table.

function vLookupDateFormat(item, field, config) {
if (item[field.fin] !== null) {
var d = new Date(item[field.fin]);
return new Date(d.getTime() + 6 * 60 * 60 * 1000).toLocaleDateString(); //the + 6 (hours to add) * 60 * 60 * 1000 fixes an issue with the dates not displaying correctly for anyone not in Central Time due to DST. Note that this will change the timestamp, but I don’t care about the timestamp as I only show the date value.
}
}

However, I recreated a previous issue I reported with vLookup in Modern DFFS I’d like you to look at.

In the build table section, I had the customizer function before and I removed it. Saved the form and then looked at the item and it said “Customizer Function Not Found” but I had no value in the Customizer Function section for that field in the vLookup configuration. I couldn’t get that error to go away, so my only choice was to remove the field from the build table config and re-add it. When I did that, I saved the form, and the error went away. However, when I went back into the vLookup config, and I went to the “Add new item” section, all of the Prefill field values I had set completely changed. It was using the same fields from the Build the Table tab, and I don’t use any of those fields.

Build table tab has:
Title
StartDate
EndDate
Status

Add new item tab has:
vLookupProjectID (single line of text) that I set to [[fieldValue:_DFFSID]]
ProjectLookup (lookup column in child list) this I set to [[item:id]]

When I removed StartDate and EndDate from Build table tab, and I readded them, I saved. Then I got a report of someone trying to add a new item where ProjectLookup and vLookupProjectID were not getting set automatically. So I go into the config and I see that the Add new item tab was completely changed. It showed the same fields as the Build Table tab. This has happened several times.

[Joe Penland]

Interestingly enough, the “ensureUser” call resolves the user properly. I wonder if this is because it is checking against the cached users on the site. The user does exist there, but the “validateUpdateListItem” call still fails because the user is still present. The user still exists in the tenant, they have just been disabled and the license has been removed.

I notice that when the edit form loads there are calls to “_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.clientPeoplePickerSearchUser”. This appears to be made by the people picker fields, and I see one call for each user to resolve. The check on the user who is unlicensed and disabled returns an empty array, while the checks for all normal licensed users return data. I tested this myself to see if this endpoint could be used and it worked for me. Would it be possible for you to use that endpoint (or tie into the calls the people picker fields are already making)?

Endpoint:
_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.clientPeoplePickerSearchUser

Method:
POST

Headers (this is what I used in testing based on mimicking the network calls, not sure what is required):
{
“accept”: “application/json”,
“content-type”: “application/json”,
“content-length”: “LENGTH_OF_BODY”
}

Body:
{
“queryParams”: {
“AllowEmailAddresses”: true,
“AllowMultipleEntities”: false,
“AllUrlZones”: false,
“MaximumEntitySuggestions”: 1,
“PrincipalSource”: 15,
“PrincipalType”: 1,
“QueryString”: “EMAIL_ADDRESS_TO_TEST@domain.com”
}
}