Forum Replies Created
-
Posts
-
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.
Hi Alex,
I see that a fix was provided for this issue in version 1.0.73. However, I feel like its only partially fixed. Here is the behavior I am seeing:
– Field1 is people picker field, Field2 is people picker field.
– Rule set field value (field1 is changed set the value in field2 from field1)
– When people are added to field1, they are getting added to field2
– When people are removed from field1, they are not removed from field2 (this feels like a bug)
– Only when everyone has been removed from field1, everyone gets removed from field2Right now I am getting around this by running two set field value actions in the rule.
– First set field2 to blank
– Then set field2 to field1 values.Thank you for all your work on this and I hope a fix will be issued in the next release, so the feature works in the most natural form than going through work arounds.
