IN_CONTEXT doesn't work on Session Object ?

[gernotlg]

Is there a way to determine if the 'Session Object' is in CONTEXT ? As the below code returns False even when a user is logged in (in which case the session object should be in context):

where cs is the name of the session object... 

Code: Select all

IF IN_CONTEXT('cs') = 'Yes' Then ..

IF IN_CONTEXT('LoggedInSystemUser') = 'Yes' Also returns False when a user is logged in.

I need to determine if a process was run due to user interaction, or from a scheduled event. I could have 2 processes, but it's quite a complex set of tasks that would be best off having only one set of processes to maintain.

Thanks.

[Jaymer]

Simple answer to this. But can’t remember right now.
Bobk answered this for me a few years back.
You’re going about it the wrong way.

[Jaymer]

Found it. Search is great.

https://www.awareim.com/forum/viewtopic ... 586#p47586

[gernotlg]

In case anyone needs a workaround for this.. I did some more tests using Schedular & Menu initiated Processes, and used my AdminLogBO to record the results.

Results: (Solution/Workaround Below)

From BOTH Scheduled (No User Logged in) processes and Processes run from a Menu (User Logged in):
IN_CONTEXT('SessionObject') = 'Yes' ............ FALSE
IN_CONTEXT('LoggedInSystemUser') = 'Yes'' .... FALSE

Which renders IN_CONTEXT Useless for either of those.

From a Scheduled Process:
if LoggedInSystemUser.ID IS DEFINED then
(some code)
else if LoggedInSystemUser.ID IS UNDEFINED then
(some code)
else
(some code)

None of this executes from a scheduled process, including the last else

Which means we can't use LoggedInSystemUser.ID, because the Rule would crash (or get ignored?) when run from a Schedule.

Solution:
Schedular Calls ProcessA1
Menu or Query Operation Calls ProcessA2

ProcessA1 Creates a Session Variable ProcessSource with an attribute to say it's Schedular Initiated.

ProcessA2 Creates a Session Variable ProcessSource with an attribute to say it's User Initiated.

ProcessA3 has ProcessSource as Input (as well as any other inputs)
ProcessA3 checks ProcessSource to determine if it's a Scheduled Task or a User Initiated task.

ProcessA1 & ProcessA2 Call ProcessA3 using ProcessSource (as well as any other inputs)

The only downfall, of course, is any sub-processes that need to know Who/What initiated the process, will need to have ProcessSource as input, and it will have to be passed down the line.

It would be much easier if IN_CONTEXT worked for LoggedIn and Session Objects, that way we could just if/then/else when we needed to know who the boss is.

[gernotlg]

Found it. Search is great.

https://www.awareim.com/forum/viewtopic ... 586#p47586

great. Thanks.. I'll keep that one in mind:

if LoggedInRegularUser.AccessLevel='System'

And search isn't THAT great. It would be great if we could search for a string. I search and search and search... and there's hundred of results with each word of my search query... or am I missing something.?

Thanks for finding what you knew you were looking for

[Jaymer]

The general search (usually) stinks.
But I was able to search “my posts”, and then further refine that to find my original Q from five years ago, and that got me to your answer.

[BobK]

From BOTH Scheduled (No User Logged in) processes and Processes run from a Menu (User Logged in):
IN_CONTEXT('SessionObject') = 'Yes' ............ FALSE
IN_CONTEXT('LoggedInSystemUser') = 'Yes'' .... FALSE

Which renders IN_CONTEXT Useless for either of those.

If a process is running from the menu, that process has no concept of any user let alone a logged in user. When that process runs, there could be 0 users logged on or 1000 users, that process will run the same either way.
If that process needs data from some users record, it needs to do a FIND for that record first.

If a logged in user starts a process from a menu, that process does not need to check if the 'SessionObject' or 'LoggedInSystemUser' is in context. That process automatically has 'SessionObject' and 'LoggedInSystemUser' available to it and it can just use the data from both.

Maybe you misunderstand what 'SessionObject' and 'LoggedInSystemUser' are.
When I log in, LoggedInSystemUser refers to me and only I have access to this LoggedInSystemUser. Some other logged in user will have access to only their data via LoggedInSystemUser. If this other user needs data from my SystemUser record, they need to do a FIND SystemUser.
SessionObject works almost the same. Only I have access to my SessionObject and my SessionObject only exists while I am logged in.

[gernotlg]

If a process is running from the menu, that process has no concept of any user let alone a logged in user. When that process runs, there could be 0 users logged on ....

That doesn't make sense.

If a process is run from a Menu, the User that selected the menu Item is logged in... so there must be a LoggedInSystemUser, which I was able to test for When there was a user logged in, but not when there wasn't. (I'd forgotten about AccessLevel = 'System' )

So my logic was: that if a LoggedInSystemUser is in Context (or a Session Object) then the process must have been run by the the user from a Menu or Query, and NOT run from the schedular. I needed a way to test when there was no user logged in.

Anyway, after getting it working with the...

Code: Select all

 if LoggedInRegularUser.AccessLevel='System'

...method, I went back to using the non persisted Session Variable, that way I could run the process as an admin from a menu, and the system would think it was run by the schedular and behave as such.

[BobK]

If a process is running from the menu, that process has no concept of any user let alone a logged in user. When that process runs, there could be 0 users logged on ....

That doesn't make sense.

Sorry, my mistake. That first paragraph should have been "... from the scheduler..."