the odd thing is, if i paste the actual script into the alarm, it works just fine. confusion abounds.
the manual is a little fuzzy, since it's from several versions ago, but this post suggested new information. it doesn't elaborate on where to put shared scripts, but at least a modification of calling project scripts.
old screenshot. userFunctions my militant efforts to standardize naming conventions: everybody here hates the underscore... fine. but be consistent.
EDIT: i read further and found that Gateway Scripts are found in the defined Gateway Script Project on the Config page under Gateway Settings. so that's one niggly bit sorted. *phew*.
The 'Gateway Scripting Project' setting should only be relevant for truly globally scoped stuff (namely, tags). Since you define alarm pipelines in a project (now, you didn't in older versions) they should 'know' about the local project's scripting environment. I want to say there's a ticket for this, but I can't find it - if indeed it's even the case.
would this not include functions we call and use on literally every project? i am wondering if, now that i actually have this global script project defined, if that possible bug can be sidestepped by calling directly from the Ignition Gateway...? i'll give it a go and report.
and, for completion sake, i'm assuming that there's nothing wrong with my syntax: it should work. it just doesn't. correct? and, moving forward with the centralized script repo concept, the call would now be: shared.userFunctions.multiUserFunctions.getUsersEmails('SomeUserSource'), correct? (and, yes, i caught my previous typo )
project script call from alarm pipeline: ........*crickets*........
as @PGriffith mentioned above, this may be a bug and i'm going to try and sidestep it with a global script call and see if that works. it's where i am trying to migrate anyway...
No, the gateway webpage that's nicely sortable and filterable.
That's not what I described nor what the setting does.
The 'Gateway Scripting Project' setting does one thing and one thing only:
It tells scripts that are executing outside of any project scope where they can look for a shared script library. Note the term project script library. There's no automatic translation of a call from client/designer scope to gateway scope, or vice versa. We're not serving up magic, even if it seems like it sometimes.
So when you are in a script that's going to be executed by the gateway (tag event scripts, gateway event scripts, Perspective scripts, alarm pipelines, reports), it will have some contextual automatic import(s), where some can be 1. the project it belongs to, if it's a resource you authored along with your project, 2. the 'gateway scripting project', if it's something that doesn't belong to a project, such as a tag, or 3. nothing, if it's a global resource like a tag and the gateway scripting project is not set.
Well, I don't know, because you haven't posted your code But conceptually I agree with your basic premise that the same text that works directly in the pipeline should work if invoked as a call to the project library.
No. You don't need any shared prefix _unless your actual project script library path includes shared. Back in older versions of Ignition, where there was a special one-off "global" project, there were two special namespaces: project and shared. As of Ignition 8.0.0, there are no 'special' namespaces - whatever names you put into the top-level of the project library are effectively automatically imported (according to the project/no project scope described above).
As a general note: Please try not to rush to pattern-match things we're describing to concepts you may be more familiar with from other systems. I promise Kevin, Phil, myself, and anyone else who's offering you advice is not trying to use confusing terminology - we're just using "standard parlance" around Ignition, which is unfortunately overloaded because English only has so many ways to describe the same things and every possible stack is just that little bit different.
oh, for sure! i speak 5 languages and am fluent in 'this-kinda-means-that-but-more-this'. i am VERY grateful for the patience you have with my questions. i know i'm a bit of an oddball, but i very much want to understand this new ecosystem.
to that end, in a nutshell, i am tasked with refactoring the spaghetti that is our current codebase for our client projects. they are all roughly similar and are doing roughly the same things. which begs for some standardization. i'm wanting to build a common repo of scripts for the more common tasks so guys aren't writing variations and interpretations of the same thing to get fundamental data like permissions, contact info, and a host of other common tasks. the problem we have is that, currently, because of the spaghetti monster of our predecessor, there's no structure to what is currently running. so i get to learn Ignition while refactoring and trying to follow the stream of consciousness that built this stuff. and coming from a strong background of development, i have old habits that need refactoring themselves.
so what i'm looking to do: build a common toolset of basic functions accessible by ALL projects
what i'm looking for: the ability to see the contents of what the current codebase is generating. i think i have that licked.
does the Gateway Script Project let me do #1? i'm still wobbly on Gateway execution vs Project execution. if i read you correctly, if i call a function the does not reside in the project scripts, it will then look for them in the Gateway Script Project. is that correct?
Projects have an inheritance structure, and scripts in one project can use the scripts in their parent (or parents) project(s). (No, not not multiple inheritance, sadly. Just linear up the chain of parents.)
Objects that live outside of any projects, like tags, merely pretend to belong to the gateway scripting project, for scripting purposes.
Since you've be posting things that include the shared.* and project.* scripting namespaces, it might help you to know that those are holdovers from Ignition v7.9 and before. In those older versions, there was no inheritance, except that shared.* scripts were visible throughout the system. The upgrade process to v8+ would create an inheritble global project with the shared.* scripts, then regular leaf projects inheriting from that, and with the global scripting project preset to global. This would mimic the v7.9 behavior in v8+. You are not bound to continue doing so, and probably should not.
I recommend you create:
A global, inheritable project that carries the old shared.* namespace and it successors. Place well-tested common functions and classes here.
An inheritable project, inheriting from the global project, that carries all well-tested common scripting functions and classes you need for your user interfaces. Include well-tested common user interface elements such as Vision templates, Vision popup windows, and Perspective views that might be considered template-equivalents. Perhaps separate global projects for Vision versus Perspective, if applicable.
Leaf projects as needed for user interfaces, inheriting from the above global UI project. New windows, templates, views, and scripting functions should live in a leaf project until they are sufficiently well-tested to be relied upon in an inheritable project.
An inheritable project inheriting from global that carries all well-tested common scripting functions useful in non-UI gateway background tasks, and all all script functions needed by tag events. Make this your gateway scripting project.
Leaf projects as needed (inheriting from the global background or global project) for gateway background tasks that are not tag events, and not intimately tied to a user interface project.
I think it's possible to achieve something like this through inheritable projects, but resource inheritance is a whole can of worms, with rules on what is ok to inherit and what will give you heartburn if you try to inherit.
Maybe you can write a module joking, mostly
Edit: Phil beat me to the punch while I was writing this. I'll just add that whatever you do, don't try to inherit event scripts like tag change scripts
this is a lot to digest and i'm going to need a bit to chew through this as i don't fully understand inherited projects yet. i need a new mental model entirely. i'm going to go, take what i have here, and tinker to try and comprehend better...
my militant efforts to standardize naming conventions: everybody here hates the underscore... fine. but be consistent.
)
why do you hate me so?? 
But conceptually I agree with your basic premise that the same text that works directly in the pipeline should work if invoked as a call to the project library.
joking, mostly
i need a new mental model entirely. i'm going to go, take what i have here, and tinker to try and comprehend better... 