Forum Replies Created
-
Posts
-
Alex, I think i have nailed down the source problem. This happens with any list used as a source. If the field that is selected to show value when you setup your lookup field is not “Title”, this error shows up. I tried selecting a field that is not “Title” for some other lists and found out that “Get information from” and “In this column” are blank in field properties in DFFS.
I tried selecting “Title” field for the list i had issue with initially and this time it worked. I hope I am making sense and you can hopefully recreate this at your end.
Alex, my apologies. The screenshot was of an edit form. However, this behavior happens in ALL forms. Fields are just regular lookup fields. I added another lookup field (Lookup2) from a different list and that doesnt seem to have an issue. From what it looks like I am only getting this error when i create lookup fields from a particular source list. Because of this error, I am not able to select any value in edit and new form with DFFS enabled.
What puzzles me is that this error does not show up in out of the box sharepoint form. And I am able to select values for this lookup field.
I have attached a gif and screenshot displaying this behavior. Let me know if you need additional data.
Attachments:
I have been using the async await syntax/pattern. Since i was awaiting an async function from within my main function, i marked it as async as well. My background is in C# and have very limited experience with async development in JS. If i recall correctly, I had received errors if I didnt have the parent function marked as async if its awaiting an async function inside it.
In my case, the getEmailsAndNames function loads all the required user information from an external script. Those functions are async as well. This is why i am awaiting those function calls within my getEmailsAndNames function. Sometimes, there are 10+ different user information i need to gather (mostly for rules that involve rules). Async/await pattern seemed to be cleaner and concise.
I thought i had 1.0.83 installed previously and it did work. Maybe it was an earlier version. I am not sure, but this method surely worked. I had tested this many times before implementing it on the rest of SharePoint lists.
What do you recommend I do in this case?
I see that there is an additional toggle option that shows up when you toggle show version history panel on top right corner of display form. I missed that toggle some how. Thank you for the quick response.
It is working. Thank you for the tip.
I am attaching a screenshot of my version history panel. I am not seeing any way to restore a particular version from lets say Display form. I do see the out of the box sharepoint version history panel and a restore option if i click the … next to an item title in a list view and select version history. Can you tell me what am I doing wrong here?
Attachments:
Alex, can you check the version of dffs package in the zip folder? After installing its showing me 1.0.70.0. Screenshot attached.
Attachments:
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 VellappillilHi Alex,
This worked great. Instead of preparing the email during a rule, i had to create another rule that prepares the email. This rule had to be triggered from custom javascript. I called this rule after child item was created successfully. This way, the email had the newRecordLink variable populated and available.
Thank you so much for your help.
I got the flow and the separate list setup and working.
What i feel could be helpful from DFFS is that if we could avoid creating the email content from JS. Instead, if a rule can be used to be a placeholder with all the emails that needs to be scheduled, that would be great. Then in the js code, we will just have to reference the rule object, loop through all the emails, get all the email data and create a new record in the custom list. This will all have to be custom code, which I understand. But if we could create the emails in a rule to be referenced later, this would make it so much easier for future maintenances. I hope I am making some sense here.
In classic DFFS we were able to look inside the rule object from JS. With modern DFFS I see only rulestate and trigger rule options related to a rule. Do you think exposing rules and it’s related data to JS is a possibility?
Thank you,
Amal VellappillilThank 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.
