10 Replies Latest reply on Jul 13, 2016 5:41 PM by ernstamort

    With great extensibility comes great responsibility...

    Rhys Kirk

      Are OSIsoft planning any ability to categorise & control extensible symbols into PI Coresight? Let me elaborate...

       

      The extensibility is great, awesome in fact, but I'm starting to wonder about a flood of custom symbols within PI Coresight that could potentially cause clutter. What I am asking about here is whether there it is on the road map to provide a categorized view of symbols installed on a PI Coresight instance? Something like the Control Toolbox in Visual Studio.

       

      Secondly, I am starting to wonder about exposing too many symbols to specific users. Are there any plans for an administrator to be able to specify groups of users (via AF Identities or whatever) who should be able to have specific symbols at their disposal? It is technically possible right now to embed that type of logic within the symbol at configuration time, but I am thinking about a built-in mechanism of PI Coresight to manage custom symbols.

       

      Tom LeBay

      Jason Golla

        • Re: With great extensibility comes great responsibility...
          Marcos Vainer Loeff

          Hi Rhys,

           

          I wonder how many custom symbols do you have in your PI Coresight? Do you think that having 20 or 30 custom symbols in a PI Coresight will be common in the future? I don't think that adding a feature as you have described if there are only 5 custom symbols on a PI Coresight.

            • Re: With great extensibility comes great responsibility...
              Rhys Kirk

              Right now, mine is a development PI Coresight instance, I have more than 5 where lots of them are half done - because I like to start some then move onto something more interesting.

              However, as we see more symbols making their way into the PI Coresight world, and when we get to the "App Store" approach for PI Coresight symbols, then it will very quickly become easy for an PI CS instance to install lots of symbols. I would put money on there being about 10 variations of the Trend symbol popping up...I've seen a couple of beta ones already.

              1 of 1 people found this helpful
              • Re: With great extensibility comes great responsibility...
                Gael

                Hi Marcos Vainer Loeff,

                 

                I fully agree with Rhys Kirk and his requests. Regarding your point, the number of symbols is not important from my point of view (I definetly think that you can have hundreds of symbols developped in the future. OSIsoft makes generic stuff and integrators make customed stuff). Anyway, we need to be able in the future to categorize and manage access to the symbols.

                If you develop a symbol which is used for a specific need (based on a business case / activity), then you want to manage the access to this symbol to be viewed by only a specific group of persons (using PI identities for example). You don't want to populate the symbol to everybody. The extensibility gives you a lot new way to customize the data view to end-users.

                 

                Regards,

                 

                gaël

                2 of 2 people found this helpful
              • Re: With great extensibility comes great responsibility...
                tlebay

                Good ideas Rhys.

                We have recognized the problem with the current symbol pallet UI when many extensible symbols are added, and I agree that over time many symbols will be added.  We have plans to change the UI along the lines that you suggest.  Nothing new in the PI Coresight 2016 R2 release, but hopefully in 2017.

                 

                The idea of allowing access to certain symbols on the pallet based on security settings is a new one.  I assume once a symbol is placed on a display any user with access to the display should "see" the symbol so the restriction is just to prevent a group of users from adding it to a display.  Is that how you see it?  Does this really need to be based on security access?  Why is it important to prevent some users from using a given symbol?  If the UI allowed the symbols to be organized better, so that casual users would not have to wade through a long list, would this accomplish the main objective?

                 

                We have plans to create a couple different types of PI Coresight user types (still subject to change).  One user type will be just like the current user; can view, create, and share display.  A second user type, lets call it a "Personal" user, can view and create displays, but not share.  The Personal user could create a display with some special symbol (maybe they know how to configure it, maybe not) for their own personal investigation but they can't share that display.  I am just guessing, but would this also help satisfy the need to restrict access to symbols based on security?  Because the user can't share, they can't share a display that would be potential misleading to other users.

                1 of 1 people found this helpful
                  • Re: With great extensibility comes great responsibility...
                    Rhys Kirk

                    Tom, the issue I have at the moment is mostly for shared instances of PI Coresight.

                    I have a PI Coresight instance where there are groups of users that are actually a 3rd party to a client. Those users are segregated in what they can see in PI Coresight via some enhancements I built (you're aware of that) - essentially the 3rd party are just read-only users of PI Coresight. The client they have a rich set of displays, for which I will build some custom symbols to simplify some of the functionality being used and facilitate a move towards normal CS built displays rather than PB hosted displays. The group of users who are 3rd party don't need to see nor use any of those custom symbols. At the moment they will see all the custom symbols.

                    The client is also split up into multiple businesses where I will create some specific business related custom symbols, which really only meets the needs for that particular business. I want to again segregate the symbols to the groups of users from each business. Generic custom symbols are fine to be shared between them all.

                     

                    If a user is looking at a display where there is use of a custom symbol they don't have access to then I would prefer a nice big red X within the symbol boundary.