As Eduard said, use a custom resource. Now it depends on what you want to do:

  • If you want to restrict certain Portal pages to a subset of users, create a custom resource (R1 for this example), add it to the pages you want the subset of users to access, and then add Use permission on the R1 resource to an existing or new role. Only users that are members of that role will have access to the pages.
  • If you want to restrict certain users to a subset of Portal pages (your question), create a custom resource (R2 for this example), add it to all the pages the users should not access, and then add Use permission on the R2 resource to an existing or new role. All other users should be in this role, and they will have access to all the pages, as they did before these changes. Any pages that aren't protected by R2 will be the only pages available to the users that aren't in the role. 

Hope that's clear.

James, for this one, there is no easy answer. But first, here are some corrections FYI:

  • Since what you're passing in to execute contains quotes ("SYSTEM"), surround that with single quotes instead of double quotes
  • Since the Security.System class is in %SYS, specify the namespace in your command.

So it's this:

csession TEST -U %SYS '##class(Security.System).AutheEnabledGetStored("SYSTEM")'

But the problem is that this expression doesn't output its value, and you can't include "write" at the beginning. You should probably describe exactly what you're trying to do in more detail, and someone here will make a suggestion.

Security.System is a persistent class with 1 object in it. The ID of the object is "SYSTEM". So this works

set ss = ##class(Security.System).%OpenId("SYSTEM")
write ss.AutheEnabled

The approach above is best if you want to access several properties. But if all you really want is one or two properties of Security.System, you can do this:

write ##class(Security.System).AutheEnabledGetStored("SYSTEM")

Also note:

  • InterSystems IRIS v2019.1 also provides direct access to globals, using a feature called the Native API for .Net. Check the doc for it here
  • The Native API for .Net can connect to InterSystems IRIS on the same machine or another machine. On the same machine, the connection speed between .Net and InterSystems IRIS is even faster than with Caché, through the use of a shared memory connection. Read more about it here.

Brendan's comment from the other thread summarizes it nicely. Here's a little more...you have 2 good alternatives to parent-children:

  • Without using either relationship option, just use a simple reference from the "many/child" class to the "one/parent" class, and add the FK constraint yourself (using "cascade"). This allows bitmap indexes in either class.
  • Simulate parent-children relationship using one-many. After setting up the one-many relationship, in the Relationship definition in the "many" class, add the bold items shown here: [Cardinality = one, Inverse = Orders, Required, OnDelete = cascade]. This allows bitmap indexes in either class.

From @Simon Player: as an alternate approach for Example #1 above:

I would be inclined to abstract all the  ‘shared’ params to a superclass (or more than one if it makes sense due to conflicts or large number of params), and inherit that class where needed in all the places where is it referenced – then simply use {..#PARAMBBB}

This is easier to manage, more balanced, and the class compiler can take care of the dependencies, and is arguably cleaner than having a number of cross dependencies (assumes there are not too many, and no conflicts in param names).

Evgeny, if I understand you, you're saying that they downloaded the quotes to a CSV file and then they read in the CSV file. I'm now wondering if/how they "chunked" the quotes. Did they read in and store each quote one at a time, or did they read in 1000 quotes into a Java array and then store those quotes, read in another 1000 and store those, etc.

It sounds like you want to do pattern matching, but for some reason you don't want to use ObjectScript pattern match syntax for your mask. So you've decided that you want to use * for "any number of any character" and ? for "a single character" which are pretty common.

Remember that ObjectScript also has the $match Regex function. So your match() method could use that syntax for the search mask and you wouldn't have to write any code to change * into .E and ? into 1E and you'd get the benefit of additional options offered by $match.

You are correct. EventData is the field to use. Here's an example  query (run from %SYS namespace):

SELECT UTCTimeStamp, EventSource, EventType, Event, EventData, Username, Description
FROM %SYS.Audit
WHERE (UTCTimeStamp BETWEEN '2018-10-27 00:00:00' and '2018-10-27 23:59:59') AND (EventData = '12345') AND (Namespace = 'ABC')
ORDER BY UTCTimeStamp DESC, SystemID DESC, AuditIndex DESC

You probably want to add a WHERE clause on the Namespace column. The docs for the %SYS.Audit class (https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic....) suggest using a WHERE clause on UTCTimeStamp to speed up the search.

I think you are asking: "If I have an object open in one process, and another process updates that object or its corresponding row, what's the best way for the first process to make sure that it has the latest version of the data?"

I recommend using %Reload(). It makes it clearer to another developer what you're actually doing. A quick glance at the %Reload() code makes me think that it would be faster than killing the object and calling %OpenId() to reopen it.

Of course, you might want to make use of Concurrency options so that if you have an object open in one process, other processes are prevented from updating it.

This is not quite an answer to your question. Just some clarifications:

  • Your example is a %Query class query, where you write ObjectScript code for the query rather than using SQL. I haven't written one of those for a while. I'm assuming that ROWSPEC and CONTAINID are required for these types of class queries, but I'm not 100% sure.
  • A "newer" way to write a custom ObjectScript-based class query, using the class %SQL.CustomResultSet, doesn't require ROWSPEC either. Sample.CustomResultSet is an example of this technique.
  • For a %SQLQuery class query, written using SQL, ROWSPEC and CONTAINID have not been required for a loooong time. They are dynamically created from the query itself.

This is nice. The only thing I'm wondering about is why there are #dim statements for regular variables? @Timur.Safin, why did you include the #dim statements? In my opinion, #dim statements for variables that are not object references are misleading:

  1. #dim gives developers that are new to ObjectScript the impression that you must declare all variables like in some other languages. Declaring variables like this is not necessary in ObjectScript.
  2. #dim's main purpose is to help Atelier/Studio provide code completion for variables that are object references. If you write this code #dim i as %Integer, and then on the next line you type do i. ,  after the period Atelier/Studio will suggest methods from the %Integer class. If you happen to accept one of the suggestions, the resulting code will not compile. This is because our datatype classes (like %String and %Integer) are not object classes.