Forum Replies Created
May 16, 2019 at 07:58 in reply to: spjs_QueryItems failing for users that don't have web level access #25293
Thanks Alexander. The odd thing we have noticed is that in the top level site collection, users do not need read access to the web for the lists.asmx, but they do need it in a site collection under the /sites/ path. I’m not sure if it is something weird in this environment or root site collections behave differently. I have compared the site collection properties in PowerShell, but they are set up the same.
Thanks Alexander, works great
I ended up using SP.SOD.executeOrDelayUntilScriptLoaded and SP.SOD.executeFunc to handle the loading of the custom JS file at runtime. I believe this similar to the require.js functionality
I’m experiencing an issue along these lines with jquery-ui.js and third party code in SharePoint Online. I’m including files at the top of the Custom JS tab. Most of the time, everything works, but every now and then the DFFS form throws the error:
TypeError: jQuery(…) addres is not a function
Any idea how I can work around this?June 15, 2018 at 00:30 in reply to: The "ListFormWebPart" Web Part appears to be causing a problem #21202
Fixed. It wasn’t any issue with DFFS. It was an issue with permissions to a list that has a lookup to the list that had this issue. The lookup column had enforce relationship behavior – cascading deletes configured.
Hi Alexander, I think there is an issue with the updated code if you use the standard filter criteria. The error appears in line 184 in the call to spjs.casc.init:
`var c, s, err = false, camlFilter = b.filter.charAt(0) === “<” ? true : false;
the b variable contains an object, which seems to fail on the b.filter.charAt(0) statement.
Thank you Alexander, that works perfectly.
Unfortunately I need to filter based on the properties of the current user, so I can’t implement as a calculated column.
I’m trying to use a Jquery statement to remove the option from the DOM, but I’m having problems figuring out where to place this. I’ve tried calling it from a rule that runs when the form is ready or initialized, but in both cases, it seems like the DOM hasn’t been populated with the cascading dropdown values yet. Any suggestions?
Thanks Alexander, I thought I had seen that option somewhere, but couldn’t remember where. Would it be worthwhile adding this to the user manual?
Is there a way to check the last execute status of a rule in code?
I’ve only used DFFS in SharePoint Online, but one potential issue is if your SharePoint 2013 environment is using classic instead of claims and you have code that reads the username from user fields, you’ll now have to handle the claims portion.
Chances are your SharePoint 2013 environment is already using claims.
Can you use multiple filter criteria when you call spjs.casc.init? I tried using the following syntax for the filter option, but the operation failed:
Or is there another option for updating the results of this call?
Is there any trick to apply more than one filter for a cascading dropdown, even if it needs to be done when the results have been returned?
I’ve tried both approaches. I found that setting the field using the Set Field Value section in a rule did not trigger the “On Change” rule I set up.
I’ve been able to use this CAML query to display a specific subfolder in a library in SharePoint Online.
Ideally I would like to show the contents of this folder expanded by default. How would I automate an onClick event? This would also solve the problem with the rendering of the initial view of the vLookup – the folder name is wrapping onto a second line until you expand it (screenshot attached).
Would it be possible to add functionality to support branching of DFFS? There are deployments where it is not practical to have dev/test/prod environments. We have to develop new functionality in production.
It would be great if we could “branch” the dffs configuration, make changes, test it, then publish it as the production version. We could use a query string or cookie to indicate whether to use the prod or dev branch when accessing forms or configuring.
The “enhanced with DFFS” tag could be updated to show which branch you are using and allow you to select a different branch.
To get extra fancy, this branching may be done at a view, list, web or site collection level. You could also include special branch tags with include files if you want to make them branch specific.
Obviously, any list configuration changes would affect all branches.
- This reply was modified 3 years, 3 months ago by Ivan Wilson.