Specifically, the $-style methods (called system methods) were introduced in 2016.1 and then removed in 2016.2. See here for details.

Indeed. IMO, %ALL is an unnecessarily well-hidden secret and I wish new installations created %ALL by default. See this post of mine for more info.

For #1, this button adds a hyperlink to a selection:

I was wondering the same thing, seeing how Kevin referred to "directory" names. But given that he tagged the post as "Studio" I assumed he meant "package" rather than "directory".

Any cconsole.log clues?

Indeed. As a consequence, some of our tools that check $ZV to tell if they're running on the InterSystems platforms or on one of the other M implementations have had to be modified to treat "IRIS" as equivalent to "Cache".

This may look alarming, but all it's doing is destroying the local variable (you named it 'stream') that's referencing your stream object. And assuming it's the only variable referencing the object, the object will be destroyed, thus closing the file it had opened.

Latest public releases of 2017.1 and 2017.2 are currently 2017.1.2 and 2017.2.1, so if you're encountering this issue you may need to request an ad-hoc build containing CDS2960.

I guess he means Management Portal. And I wonder if a long-running SQL operation initiated from there might be adversely affected by a CSP Web Gateway timeout.

Also, a similar kind of check using a method of %SYSTEM.Security is not case-sensitive with respect to the username:

USER>w $system.Security.CheckUserPermission("laura_test_DEV","%Development")
USE
USER>w $system.Security.CheckUserPermission("laura_test_dev","%Development")
USE
USER>w $system.Security.CheckUserPermission("laura_test_devX","%Development")
 
USER>

The priv check is case-sensitive on the username:

USER>w $system.SQL.CheckPriv("laura_test_dev","9,%Library.File_FileSet","e","USER")
0
USER>w $system.SQL.CheckPriv("laura_test_DEV","9,%Library.File_FileSet","e","USER")
1
USER>

Anyway, I'm glad it's now working for you.

BTW, to paste an image into a DC post I save it to a file, then use the following button in the DC editor to upload the file:

And then I sometimes (as above) use the Image button on the toolbar to add a 2-pixel border to the image, then the Increase Indent to move it across.

Are you sure that you granted your test user the EXECUTE privilege on the procedure in the actual namespace where it will be executed?

I created a new user "laura" who only has the %Developer role. From the USER namespace in Terminal she can't prepare the class query:

USER>w $username
laura
USER>w $roles
%Developer
USER>
 
USER>s st=##class(%SQL.Statement).%New()
 
USER>s ok=st.%PrepareClassQuery("%File","FileSet")
 
USER>d $system.Status.DisplayError(ok)
 
ERROR #5540: SQLCODE: -99 Message: User laura is not privileged for the operation
USER>

Then in Portal I granted her EXECUTE on the procedure, per my previous screenshot, being careful to do this in the USER namespace. Now the test results are as follows:

USER>k
 
USER>s st=##class(%SQL.Statement).%New()
 
USER>s ok=st.%PrepareClassQuery("%File","FileSet")
 
USER>d $system.Status.DisplayError(ok)
 
USER>

And here are a couple of lines where I confirm that the user "laura" has the necessary privilege in the USER namespace but not in the %SYS namespace:

USER>w $system.SQL.CheckPriv("laura","9,%Library.File_FileSet","e","USER")
1
USER>w $system.SQL.CheckPriv("laura","9,%Library.File_FileSet","e","%SYS")
0
USER>

A long shot: if auditing is turned on, and the %System/%Security/Protect  event is enabled, does anything get logged when the user encounters the failure?

Failing that, can you debug through the %PrepareClassQuery method of %SQL.Statement in the context where it's failing for you? Not so easy when the call works for your user when run in Terminal.

It didn't occur to me either! Interesting that the "Open Resource" dialog opted to use the term "camel case" instead.

Thanks for the tip Roger. As shown in your example, that dialog also does some clever stuff with CamelCase filters.