Where are the schedules?

I’m building a user administration window that will be accessible from within the project to allow a designated user or users to administer the users for which they have permissions to do so.

I have built a table that shows the administrative-type user all the users that he can administer. When he double-clicks a user, it pops up a window with that user’s details, i.e. first name, last name, username, password, etc.

I got to the schedule field and added a dropdown list with which to select the schedule to use. I was thinking the different schedules would be in a table somewhere that I could query to fill the dropdown list, but I don’t see them in any schema of our mySQL server. I could have overlooked them, but I’ve never overlooked anything in my entire life. :unamused: Where can I find these schedules?

The schedules are stored internally. Fair warning: we’re making our own built-in components for user, schedule, and roster management! You might want to hold off on spending time building these yourself.

If for some reason ours aren’t sufficient, we can add a scripting call to list all available schedules.

One of the main reasons we switched to Ignition is to allow users with higher level permissions to do the administration of their peers. With Wonderware, we have to add and remove users, edit their contact info, change their schedules, add alarms to groups, etc. This is not something we want to continue doing, as it is very time-consuming, and really not something we should be doing anyway. And it gets worse all the time as new alarms, users, and groups are added.

The goal is to create windows on the app that allow the admin type users the ability to administer the guys under their supervision, and only those people. The role mapping of the user determines if he has admin rights, and other roles determine which group or groups he can administer. The roles of his team members can be used to match them to him, so they are the only ones he can manage.

I hate to throw a wrench in the works, but this is very important to us. I sure hope you arrive at a method that allows us this capability. If you need more information or clarification, I will be glad to talk with you anytime.

Hopefully our components will be able to handle that, although what you mention is a pretty high degree of specialization.

For example, suppose I am a user, and my role lets me administrate some sub-group of other users. What roles am I allowed to assign to them? how does all of this get specified?

If your component for users allows us to write an optional query that joins the user table and any other tables we need, we can fill the component with only the users we want displayed in it. In other words, if we have two areas, and the admin-type user is in Area A, we would want the component to only show users from Area A. If we build an Area table and a User-Area-Mapping table, we could easily select users in Area A to fill the component when the Area A admin is logged in.

But that would require that when the submit is done in your user component, it would also need to fire off an event with which we could do anything else needed for that new or modified or deleted user via a script. In this case, we would add or modify or delete the User-Area-Mapping table entry for that user.

The same goes with the roles, schedules and rosters. Each area would need their own roles, schedules and rosters that only they can add, modify, or delete. Again, if you allow joining other tables with your ‘internal’ tables to fill the component, and fire an event on submit, we can maintain Role-Area-Mapping, Schedule-Area-Mapping and Roster-Area-Mapping tables to handle the added complexity. If the component didn’t use a custom query to fill it, then it could show all users, roles, schedules, or rosters through a default query, as you have planned.

With these two capabilities, we could have as many levels of grouping as needed, with management at any or all levels of the hierarchy. You wouldn’t have to worry about anything over the user level. This would open Ignition up to handle as complex a scenario as needed, or just keep it simple, if complexity is not needed.

I agree with RRRancher. Our customers are asking for the same thing. they want to be able to handle everything from the client end. as a matter of fact, I am working on getting a new project for another very large redundant system with 2000+ devices and one of the customers requirements is as follows:

[quote]5. Alarms – user configurable
We need the ability to setup, view, receive and acknowledge different types of alarms for devices in the system. The alarms need to be user configurable. We need to have email, text, and call-out alarm notification options available.
We currently use alarming software Win-911 as our primary alarming solution. It provides us with the ability to setup all alarm notification types mentioned above, however it does not work well for allowing users to configure their own alarms. We would prefer that most all of the alarming functionality be integrated into the HMI client and be configurable by general users.
[/quote]

The customer really wants to use ignition, and they have been following asking about the upcoming alarming features, but Im not sure how much of what they want can be done just yet. I also have 5 other existing systems where the customers want the same thing.

The current alarming allows them to partially do this, but it doesnt have the ability for voice, remote acknowledgement, escalation, and retries, but at least it can all be done from the client. I hope that the newer alarming features follow that path, but I am not sure it will fro what I have seen so far.

I will say that you guys could become a much bigger player in Oil and Gas if you did this. everyone wants user configurable alarm notifications, but the only ones that I know that offer it are software as a service companies like Elynx, nothing out of the box like ignition. I believe I can integrate with topview sql and automate it to some extent, but I would rather give that money to Inductive Automation than to another company.

ok, off the soapbox!

The thought processes for Oil/Gas customers varies from a standalone plant perspective. The alarming as it is now and in current Beta is great for a one facility viewpoint. Moving to multiple processing plants or facilities in multiple geographical areas start to present problems with alarming, views, and other areas of the software. One project will be used across multiple areas where each area does not want to see/view/modify the other even though they work for the same company.
Y’all are doing GREAT work and I agree that it is much better to enhance the Ignition platform than give $ to other systems out there.

just to expand on how our system is designed, users are assigned to groups of devices. we have about 10 different “roles” some having only view capability, to some having full administrative rights to do everything in our system. we have people from ceo down to the lowest man on the totem pole logging in.

some users are assigned all groups(like a VP), but others are only assigned groups that are relevant to them(like an operator handling 50 devices). these groups of meters are spread out across the US into different regions. We have some in south texas, some in west texas, arkansas, panhandle texas, louisiana, etc. each region operates as its own entity. they have their own devices, their own alarming needs, and their own way of reacting to alarms. people and alarming change really quickly. we have “power” users in each region that are capable of handling alarms and understand how they need to work because they have been doing it with other systems like Elynx.

we can handle segregating who can or cant do things and also putting in place the controls to where someone doesnt screw up! Just give us the tools to do it!

Our customers desperately want this. They love Ignition, but alarm notification is the most critical part of our industry.

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.