Keith Hudson

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 94 total)
  • Author
    Posts
  • in reply to: Bug Report for release dated 2019-01-12 #30938
    Keith Hudson
    Participant

      Alex; I didn’t respond earlier because the site owner elected to simply change the titles of the offending items, so no follow-up was needed. I have another site owner using a different version of DFFS (4.4.4.22, released 2020-02-02) experiencing the same problem. The DFFS display form will not render for items with an apostrophe in the title.

      When I examine the Console after loading the page, I’m seeing a number of errors. Whether they are caused by DFFS or by something else running in our environment I do not yet know. The two likely culprits are
      1. a function called “SafeRunFunction” that is undefined (the apostrophe breaks an js statement inside a function called BuildBreadCrumb – probably not yours)
      2. _spPageContextInfo is undefined inside a javascript function immediately following

      <!– DFFS CEWP Loader – February 02, 2020 –>

      .

      I’m attaching a screenshot of the Console errors, and of the code referenced by the second error.

      In this case, there are currently 22 items on the list with apostrophes in their titles, and it appears it may be an ongoing challenge since titles contain words like “Don’t”, “Wasn’t”, etc.

      If the underlying problem is a bug in SharePoint, not your code, we could perhaps create a workflow that removes any apostrophes from titles on list items.

      in reply to: Bug in installer v 4.4.4.30 #29469
      Keith Hudson
      Participant

        One other thing I noticed when testing: If I tried to enter the backend from the “Direct To Backend” link on the installer page, I saw my DFFS Installer page (without displaying the installer web part) for a couple of seconds before the overlay displayed.

        in reply to: Bug Report – Radio Buttons #28757
        Keith Hudson
        Participant

          I did a quick test on another site and the radio buttons worked without a problem using version 4.4.4.22. I was helping Karen Flaxer, so am not able to test it again in her site right now, but its good to know that it is working. If I get a chance, I will try to see if I can recreate the issue in her site and report as much information as I can to you.

          in reply to: Export Form Settings to different SharePoint List #27813
          Keith Hudson
          Participant

            I’ll call your original list A and your new list B, and I’ll use the new form (newform.aspx) by way of example. Make sure you have applied DFFS to the newform on list B. Open the DFFS config for the newform on both lists, A and B. On list A, open the configuration page called “Import, Export and Restore”. Choose the Export button. Copy the code that is shown, then on list B, open the Import, Export and Restore configuration page, click the “Import” button, and paste in the code on your clipboard. Click the Save or Import button (I don’t remember exactly what the button is called off the top of my head) and your configuration is now applied to the newform of List A. Make sure to save the configuration. Rinse and repeat for each form on which you are using DFFS.

            in reply to: General DFFS enhancement suggestions #26314
            Keith Hudson
            Participant

              If I recall correctly, in version 4.4.4.0, there are colors entered in the Form background color setting in the Misc tab by default when a new config is created. I actually like having the default colors there, but having readonly fields adopt the same background color as is set in the Form background color setting makes the form look much nicer than having the readonly fields end up with white backgrounds while the editable fields have shaded or colored backgrounds.

              in reply to: General DFFS enhancement suggestions #26280
              Keith Hudson
              Participant

                Please have readonly fields adopt the same background color as formfields, eg:
                .dffs-readonly-inner{
                background-color:#e3e0e0;
                }

                in reply to: General DFFS enhancement suggestions #26230
                Keith Hudson
                Participant

                  2 New Requests:
                  1. I often get requests to change the wording of the Save button to “Submit”. Can that be added as an option on the Tab configuration page?
                  2. I also get requests to hide the Cancel button. Can that be added as an option on the Tab configuration page?

                  in reply to: General DFFS enhancement suggestions #25985
                  Keith Hudson
                  Participant

                    Suggestion: Add one more instruction in the tooltip for the “Set Field Value” setting in a rule.

                    I keep forgetting how to enter the current user’s email address (NOT a mail-to link) in a people field using the Set Field Value setting in a rule.

                    It’s a bit confusing:1. {currentUserEmail} will insert a mail-to link. 2. {currentUser:EMail} will insert the actual email address, which is VERY helpful when trying to populate a people field.

                    In the next release, could you add a note in the tooltip about using {currentUser:Email} to insert the user’s email address?

                    Keith Hudson
                    Participant
                      in reply to: Non-minimized code to develop inline editing? #24976
                      Keith Hudson
                      Participant

                        Thank you Alex. I had not looked at the earlier post, so I’ll see how far we get with that. There are very smart people helping me with this effort, so that blog should give us/them the hints we need to play with inline editing. I’ll let you know how it goes.

                        in reply to: Default Entry for People Picker Field #24664
                        Keith Hudson
                        Participant

                          I do it by setting the field to {currentUser:Email}. Using JUST {currentUser} inserts first and last name as separate entries which does not resolve correctly. The results may be different in different SharePoint farms.

                          in reply to: General DFFS enhancement suggestions #24192
                          Keith Hudson
                          Participant

                            Travis, I think you could accomplish that with existing functionality quite easily by using the “Load these CSS files ” section in the Custom CSS settings page in the DFFS configuration for your forms. Save your custom css as a css file, store it in your SPJS library, and then just add the reference when you create a new form.

                            I *THINK* there is even a way to add it to the “Plugins” folder in the SPJS library so it is automatically included in every form. Check the DFFS manuals (Installation and User Guide) online.

                            in reply to: DFFS Working for Certain Users Only #24190
                            Keith Hudson
                            Participant

                              Josef,

                              This sounds like a permissions issue. If you have Check In/Check Out turned on in your SPJS library and did NOT check in the DFFS files in your SPJS library, your users won’t be able to read them, hence they will get the native SharePoint form.

                              It that is not the issue, check user permissions in the permission settings for the SPJS library using the “Check Permissions” icon in the ribbon. Also, make sure that permissions have not become fragmented in your library. Look for the yellow information bar on the permissions settings page for the library (or the site, if your SPJS library inherits its permissions from the site itself) and if it says “Some content has different permissions: click here” follow that link to find fractured permissions and re-inherit up to the SPJS library level.

                              Good luck tracking it down!

                              in reply to: Make a "Copy" button #24188
                              Keith Hudson
                              Participant

                                As an alternative, would it be possible to use the vlookup functionality to create new items passing in fields from the current item, by selecting the current list as the target of the vlookup? It seems to me that I have used vlookup to SEE related items on the same list — would that also work for creating new items on the same list?

                                in reply to: General DFFS enhancement suggestions #24010
                                Keith Hudson
                                Participant

                                  Using vLookup from the New from when no ID is needed.

                                  Currently (release date 2019-01-12) in order to have the vLookup functionality operate on the New form, I must include the _vLookupID column on my parent list even if I am using a different field to identify the child records I want displayed. (I’ll give the use case below.)

                                  My user asked how to create the equivalent of an Infopath Repeating section in DFFS. The example she gave me was based on the child records sharing the same AU (stands for ‘Accounting Unit’, similar to a GL code in an accounting system) as the parent records, which doesn’t rely on the ID of the parent record OR the ID of the child record, but I still had to add the _vLookupID column on my parent list for the vlookup config to work.

                                  If it is easy to turn off that validation when someone is not using the ID column on the parent list to relate to records on the child list, it would make setting up the lists easier for my user’s use case.

                                  USE CASE: One team supports many applications. All the applications supported by the team fall under the same AU (think GL code) as the team falls under. The purpose of the new system is to show which applications are supported by different teams (select Manager name and see all the applications the team supports.)

                                  A table of some applications and the AU’s they fall under is already available so the child list could be pre-populated through a bulk load. When adding a new manager to the parent list on the new form, immediately all the applications supported by that manager would show up on the form. Apps supported by the manager’s team NOT already pre-poplulated would be added individually on the parent list new form. At no time would the ID of the parent record be needed to find the related records on the child list.

                                Viewing 15 posts - 16 through 30 (of 94 total)