Forum Replies Created
-
AuthorPosts
-
OK, I figured it out. No need for an internal save function. This does the trick:
jQuery(‘input[value=”Save”]’).trigger(“click”);After further work, it looks like I was making an error in the placement of the quotation marks in the expression.
It is working now. I don’t know what happened, unless I had some tiny error in the code and didn’t notice it, or we had some kind of server glitch.
I’m trying it from the Console on the DFFS config page and it is not working. It SHOULD work there, correct?
make all visible tabs readonly, and set current tab fields to editable:
https://spjsblog.com/forums/topic/easy-way-to-make-all-fields-readonly/
Get current user name
var userInfo = spjs.utility.userInfo(spjs.dffs.data.currUserID);
// userInfo is an object with multiple properties – use console.log(userInfo) to see all
// Here is the title
alert(userInfo.Title);from: https://spjsblog.com/forums/topic/internal-function-to-get-current-logged-in-user/
This is not a DFFS or javascript answer, but simply a reminder of some of the built-in capability of SharePoint that MIGHT meet your need, just in case you haven’t considered it.
A.
In a Quick Edit view of a SharePoint list (or in the Datasheet view in SharePoint 2007 and 2010), the last line displayed on each page in the view is a blank line. That line is a data entry line that can be used to enter a new record on the list.You can copy and paste from Excel into that blank line to enter multiple new items at once.
In your example (50 new items each with 14 of the 15 fields on the list identical), you could create an Excel spreadsheet with 50 rows containing the 14 fields you need to repeat in each new record, and copy all 50 then paste them into the last row in a view of the list. Make sure that the field order is the same in both the Excel sheet and the view. Also, make sure the 15th field is not required, as you will be leaving it blank, then going back to finish filling that field in.
B
Change the list settings so the repeated information you want in each of the 14 fields is the default for that field. That way, when you open a new record, the 14 fields will populate with the desired information and you only need to fill in the 15th field.I don’t know your exact use case in detail, so it is possible that neither of these approaches will work for you, but I just wanted to make sure you are not overlooking a simple built in approach in case it will meet your needs.
NOTE that the “Append to existing text” choice is horribly misnamed. It would be better named “show prior versions”. I never use it. Ever. Instead, I use a multi-lines of text plain text field.
The easiest way to use it is to manually add text to the plain text field. Usually, however, I want to include a date and author stamp for each added piece of text, so just above that field on my form I insert a button using an html section, that runs a custom javascript function to create a timestamp and author stamp and pre-pend those to the existing text in the field, and position the cursor so I can just type my additional text after clicking the button.
IF you need more details, post here and I’ll try to get time to capture some code and screenshots and add them to this discussion.
This is an example of how avoiding spaces, special characters and leading numbers when column names saves grief later on. The encoding is done differently in different situations, so it can become very confusing.
I’m sure you’ll hear something on this question from Alex, but for what its worth, I had clients a few years ago who migrated from SharePoint 2007 where they were using a very early version of DFFS and we had zero problems. Of course, you need to make sure that you migrate the SPJS library and the configuration list.
More recently, I used Sharegate to copy a site using a more recent version of DFFS from one farm to another (both SharePoint 2013). We found that our (very complex) DFFS forms did not work correctly, until we exported the form config from the form on the old site to the form on the new site. We never figured out exactly why, but the fix was so easy it wasn’t worth figuring out the root cause.
Bottom line, after migration, check all the forms using DFFS in the new location. Even if they don’t work right after migration, I’m sure you will find it easy to fix them.
NOTE that as at present, based on my current understanding (which could be out of date) DFFS does not work on the forms associated with “modern” lists and libraries in SharePoint Online, but you can still change the settings on those lists and libraries to return them to classic view, and DFFS will work just fine.
I don’t know whether SharePoint 2016 contains “modern” lists and libraries. Maybe someone who knows could enlighten me on that point.
It seems to me that a simple way to accomplish that goal would be to build a workflow on list A that checks for a change in value in the Display ID field, and if found, updates all the matching records on list B.
Using DFFS to update the child values may fail if someone updates the DisplayID field on the parent list in a view, rather than through the edit form, since DFFS functionality operates in the edit form only.
If I were doing it, I would add another field to list A to record the value of the DisplayID field for comparison purposes, since I would want my workflow to run every time an item is edited, and I would need a way to know if the value of DisplayID had changed.
I hope this helps.
While troubleshooting this issue we came across another dev instance of the same web site which uses the 4.3.60 and does NOT throw an error, so we will hunt further and find out why the error is being generated. We have proof now that it is NOT DFFS. We will undoubtedly find out it is human error!! LOL
#1. The way I have approached unique ticket numbers in the past is to use the ID number generated by SharePoint, but fancy it up just a little by prepending something to the number, such as “WBT-1470” instead of just “1470”. I create a single line of text column for the ticket number, and populate it on item creation through a simple, one step workflow. I’ve never had a problem with the workflow not firing. If you are determined NOT to use a workflow, this will not work, obviously.
I’ve seen several articles online on how to pad the ID number so you always have a 5 digit number, for instance, but I just like to keep it simple.
The challenge in using the SharePoint ID number is that it does not get assigned by SharePoint until a new item is saved. (It might be tempting to write some javascript to find the highest ID number on the list, and populate a ticket number field in the new item using that, but then you have to worry about collisions.) So, if you MUST know the ID number BEFORE the new item is changed, my approach won’t work.
#2. Just a quick thought on this one, that perhaps a TicketPriority column on the new form for a ticket that concatenates the Request Type and Priority values (via a rule) would allow you to use Cascading Dropdowns to get the SLA from the external list. Simply add a new column to your external SLA list with all the possible concatenated values.
Good luck.
-
This reply was modified 7 years, 11 months ago by
Keith Hudson. Reason: Added paragraph about padding the ID number
You can use this snippet to insert a timestamp in Custom JS:
spjs.dffs.buildValStr(“{timestamp[dd.MM.yyyy hh:mm:ss]}”);
// Outputs 03.02.2018 16:27:06From https://spjsblog.com/forums/topic/using-timestamp-in-custom-js/
It would be nice if the txt file at the root of the DFFS folder that shows the release date could also contain the version numbers of each of the component files. Right now, they only way I know to check the version numbers of a release is to install it and open it, or perhaps hunt through the Change Log on the spjsblog.com site.
For example, the contents of the file v2017-07-31.txt could read:
This file is used to quickly see the version date and changed files.
Changed files in this release:
——————————-
/DFFS/js/DFFS_backend.min.js (v4.4.3.7)
/DFFS/js/DFFS_fontend.min.js (v4.4.3.7)
/DFFS/js/DFFS_backend.css (v4.36)
/DFFS/css/DFFS_frontend.css (v4.36)
/DFFS/plugins/SPJS-ac.js (v1.6.11)
/DFFS/plugins/SPJS-casc.js (v3.7.9)
/DFFS/loader/DFFS_loader.html (v?????)Files not changed in this release:
———————————
/DFFS/plugins/jquery.min.js (v1.12.4)
/DFFS/plugins/SPJS-vlookup_backend.js (v2.2.98)
/DFFS/plugins/SPJS-utility (v1.307)
etc. -
This reply was modified 7 years, 11 months ago by
-
AuthorPosts