Where are the schedules?

I’ve been thinking about this a lot. There must be some good reason why you want to have the security tables internal to Ignition. But if you were to keep them external, i.e. in a SQL database or Access or whatever, you could still use your components, I would think, and we could join these tables any way we needed to do so for our more complex methods. From our perspective, it would seem that would make life much easier for you, and require nothing more than what you already had.

If you are doing them internal for speed and/or not having to rely on a link to the database server, I can relate. Database connections aren’t always instantaneous. But the tables we are talking about here are not something that are updated constantly, and as long as there are copies of them in the external database where we can access them, you could read them when the client starts up and keep internal copies for runtime. If a change was made to one of the internal copies, an update to the external tables could be made at that time.

I’m not trying to tell you how to write Ignition here. I’m basically thinking out loud in case it helps. As Todd and diat150 have said, it’s a different world out here in the oil and gas industry. It’s like little factories all over the place, each with its own managers and workers and equipment. And believe me, none of them want to do things the same way as the others. We simply have to be able to change the security of the app programatically to fit the needs of Area A as opposed to those of Area B, etc. I can almost assure you that any other oil and gas customers you have, or will contract in the future, will be needing the same thing, unless they are fairly small and only located in one area.

You guys have some awesome software here. If we were factory types I doubt we would have any problem using the production version to do anything we needed to do. We just want to be able to use it in our world also. It beats the heck out of anything else I’ve seen so far. Keep up the good work.

Ok this is good stuff.

First of all, as far as “internal tables” goes, remember that there is still the database-based auth profile. So you can have that stuff in your own tables if you want. The exception here is schedules and call rosters, which we can (will!) easily have scripting access to.

While it’s true that the built-in components we’re working on are primarily aimed at making things easier for our “normal” use-case, it’s also true that here at IA we don’t really have “normal”. A very large swath of our customer base requires lots of customization.

I think I have a pretty good idea of what we need to allow these components to be used for you guys. What I want to do is let you insert little (optional) snippets of scripting that will be used like a filtering predicate. So, when we load the list of users to administer, we then pass each user to your script, which can return either 0 or 1 if you want that user to be shown. Same for roles, etc, etc. This is an idea that’s been bouncing around for a while which I’m calling “Extension Functions”. Not promising this feature by the dot-zero release, but it will get in there. I just want to make sure we have the time to do it right.

Good deal, Carl. We are all hoping that you can get it in the first production release so we don’t have to use the current production without all the alarming goodies and then redo everything when it becomes available. But I understand deadlines and all.

For some reason, I was thinking you were going to make the users, roles, and mapping tables internal-only, also. But now that I think of it, they are used for the gateway also, and would have to be available to begin a new project.

It sounds like your filtering method will do the trick just fine. As long as the filter can be based on a query of SQL tables, it should work just fine. We can work with that.

I didn’t mean to imply that you had a normal on everything. Sorry if it came across like that. I was really talking about the simple security method where the entire application’s security relies only on the users, roles, and mapping tables. This probably works fine for the majority of your customers. Leave it to the oil and gas guys to throw a wrench in the works. :slight_smile: Thanks for the quick reply. If we can be of any help in testing or whatever, please don’t hesitate to let us know.

[quote=“Carl.Gould”]Ok this is good stuff.

First of all, as far as “internal tables” goes, remember that there is still the database-based auth profile. So you can have that stuff in your own tables if you want. The exception here is schedules and call rosters, which we can (will!) easily have scripting access to.

While it’s true that the built-in components we’re working on are primarily aimed at making things easier for our “normal” use-case, it’s also true that here at IA we don’t really have “normal”. A very large swath of our customer base requires lots of customization.

I think I have a pretty good idea of what we need to allow these components to be used for you guys. What I want to do is let you insert little (optional) snippets of scripting that will be used like a filtering predicate. So, when we load the list of users to administer, we then pass each user to your script, which can return either 0 or 1 if you want that user to be shown. Same for roles, etc, etc. This is an idea that’s been bouncing around for a while which I’m calling “Extension Functions”. Not promising this feature by the dot-zero release, but it will get in there. I just want to make sure we have the time to do it right.[/quote]

how about the pipelines and notification blocks? can you envision a way to add new/delete/edit groups without having to go into the designer? I dont want to sound overly anal about this, but it is priority #1 for our customers. I certainly appreciate you guys posting on a forum with us and actually listening. Its truly a breath of fresh air compared to your competitors.

I totally agree with diat150. Being able to talk directly with you guys here on the forum is wonderful. And I understand that as you grow and obtain more customers, things may change. But for now, it’s a good thing to have direct communications instead of having someone pass it along where important things get lost or misconstrued. I have to say that you guys have the best user support of any company I’ve ever dealt with. Kudos to all of you for that.

Carl, I got to thinking about this last night, and I may have spoken too soon. Yes, your component allowing us to filter the contents via joins to SQL tables should work just fine. But what I realized is that we still will need some mechanism to fire an event we can recognize when the submit is done on the component. That is because we will have to, in many cases, insert, update, or delete something in our SQL tables when the submit is done.

For instance, if we use your users component to delete a user from the system, we will also need to delete any entries for the same user in our Area-User-Mapping table, and perhaps others as well. Something as simple as the LostFocus event for the component would work. Anything to fire an event with which we can script whatever else we need to do. Is that doable?

I just read your last post again, diat150. We were brainstorming yesterday about how to let the supervisor types manage the way alarms are handled, and I think we came up with a way to do it programatically. I don’t have time to test it right now, but I think it will work. It involves using the IA Scripting stuff to modify the DisplayPath tag in the UDT instance, and expressions or switches in the pipelines to branch off to the desired alarming method by looking at the modified DisplayPath tag in the UDT instance.

Having an event on save seems doable.

diat150 - can you elaborate on what you’re trying to achieve when you say “add new/delete/edit groups” and talking about pipelines?

He can correct me if I’m wrong, but I think he was talking about rosters, not groups. That is what we always called them before Ignition came along and I may have used that term in a previous post also. Old habits. :slight_smile:

Well, altering the rosters in the client is part of the components I’m talking about. To recap: these components will be able to modify: users, roles, contact info, schedules, and rosters

[quote=“Carl.Gould”]

diat150 - can you elaborate on what you’re trying to achieve when you say “add new/delete/edit groups” and talking about pipelines?[/quote]

what i am referring to as a “group” is an alarm or set of alarms that are assigned a name and have their own distinct callout roster.

lets say pump1status, pump2status, and pump3status are tags I want to do notification on to the same set of people. typical alarming software will let you assign these tags to a group. from there, you would assign users to notify to this group. you can even have a tag that is in multiple groups. an example of that would be a comm status alarm. you could have a group for a device that contains the device comm status along with say a pressure alarm. that group would be assigned to the operator that takes care of the device and only sends alarms to him. you could also have another group that has comm status tags from every device in the system. that group would be assigned to an IT guy that monitors communications only, and would email him when any comm status tag goes into alarm.

I havent completely studied everything but it seems that you will have to do pretty much everything in the designer to start, then after everything is setup, you can modify the roster and then user configs like contact info and work schedule.

We talked at length about this with a prospective customer today. They have a large system with 1000+ devices. They essentially want a user to be able to login to a client. decide which tag or tags he wants to get notified for, which method of notification to use, then click a button and it will be setup. additionally, they want the ability to come back and edit that to include more users(or the order of contact) if necessary or delete it altogether. There could be hundreds of groups(tag or set of tags that need their own roster) in this system. I just dont see that happening with the new notification system(maybe I just dont completely understand it yet). The old system was much closer to providing that capability, except it did not have escalation.

sorry for being long winded :smiley:

Carl, just wanted to stop by and see what your thoughts were on the above post.

Well…I’m not sure exactly how you’d do that. In your example, I think you’ve glossed over some important details. If a user simply browses for tags he/she is interested in receiving alarms on and checks them, how is the order of delivery defined? Also, a system like the one you describe has no escalation.

We’re fairly resistant to the idea that an alarm system should be deployed with the mentality of: “Well, we don’t really know who should get what, so we don’t want to define it. We’ll just let the operators decide.”

I think what you’re describing is more of an operator alert system, not an alarming system (it might sound like I’m splitting hairs here, but I’m going by the terminology from the handbook.) I’m not sure yet whether our alarming system will morph into something that can accommodate both styles of systems, or whether someday we’ll tackle the idea of an operator alert system. It may be that all we need is some kind of scriptable pipeline block to help bridge the gap.

[quote="Carl.Gould"]Well....I'm not sure exactly how you'd do that. In your example, I think you've glossed over some important details. If a user simply browses for tags he/she is interested in receiving alarms on and checks them, how is the order of delivery defined? Also, a system like the one you describe has no escalation.
[/quote]

yeah I dont know Carl. I thought I explained it pretty well. Im just relaying to you guys what our customers are asking for. If you guys can deliver this feature it makes it a no brainer when they compare ignition to other software packages. If you would like to speak with some end users to better understand this requirement I can arrange that.

[quote]We're fairly resistant to the idea that an alarm system should be deployed with the mentality of: "Well, we don't really know who should get what, so we don't want to define it. We'll just let the operators decide."
[/quote]

I dont see the issue with having a operator manage their own alarm requirements. At the very least the area managers want a power user to be able to configure the alarming requirements for their area thru a client interface. Being able to do everything from the client is the key. Its our job to make it pretty and useable for the end users and fit whatever model they would like to use. we just need the tools to do it.

Well I certainly hope you guys can come up with something that can meet our needs. Like I said earlier, this is important to all of our customers. They are willing to pay for it. I can have at least 3-4 of our customers speak to you about this if you would like. I know the other guys in this thread are looking for similar functionality also.

Well, we have some ideas for a scriptable notification block that I think would satisfy your requirements pretty nicely.

awesome. If you guys would like to have a gotomeeting to look at our system to get a better understanding of what we do and how we do it then we can definitely arrange it.

I appreciate your time.

Ok diat150 and RRRancher - in beta-6 we’ve introduced extension functions. On the user admin component these will let you insert your own logic to filter the user/role lists down based on who is currently logged in. There are also hooks for when the save button is pressed. Here’s a sneak peek:


The table component got some too. I imagine we’ll add more of these as we think of good ideas for them.

Looks good, Carl. I will take a closer look at it asap. Unfortunately we removed the beta and installed the production Ignition to get a working project done by deadline. I may not get a chance to look at the beta again until next month, but from your post, it looks like the extensive functions will allow us the flexibility needed to modify the project depending on the user that is logged in. I appreciate your work, sir. It is so refreshing to be working with a software company that listens to the needs of its customers, and doesn’t take months to produce results. I sure hope you guys stay this way as you continue to grow. And I know I’m not the only one that feels this way. Thank you very much.

I just had a chance to try the Extension Functions for the Roster Management. While I can use these functions to do what I need to, I’m not sure the best way to go about it.

We are currently using database security and have a lot of time and effort into custom tables and queries. This is mainly to break users into organizational groups similar to what RRRancher mentioned. Supervisors of these groups will only be concerned about a specific roster and a group of users that they manage.

I can use the filterRoster to limit the roster to what they need, but a property that works like the User Source would be easier. I can use the filterAvailableUser to run a query on each user and see if they are in the group that the supervisor manages, or check to see if they have a specific role. I’m concerned that the larger our system gets the slower this approach will be. Being able to run a query to get a list of Available Users would easier.

I have been doing some testing with the new management components using an AD Internal Hybrid user source. There is one major thing missing that is preventing me from using this type user source.

When using the User Management component, there is no way I can see to know when a user is deleted. If a new user is added, or if I modify a user, the onSaveUser function is triggered, and scripting can accomplish anything else needed. But If I delete a user, nothing is triggered, so I have no way to run a script to remove that user’s records from various tables. Seems like an onDeleteUser extension function would be easy to add to the User Management component.

Ill jump in also…any update on scriptable rosters/pipelines?