11 Replies Latest reply on Apr 7, 2011 10:04 AM by andreas

    Restricting user from modifying ProcessBook PDI files.

    formerpigeek
      Hi, How to avoid any user modification of the PDI files while displaying them in ProcessBook? PI ProcessBook by default displays all the standard menu items and this would allow the users to switch between Run and Build mode, hence enabling the user to modify the screens. I have to restrict the user to Run mode and not allow them to change it to build mode unless he/she has the permissions. Is there is a way where in I can show the ProcessBook only in Run mode and hide all of the standard menus. Thanks & Regards Kavita
        • Re: Restricting user from modifying ProcessBook PDI files.
          Bannikov

          Hello!

           

          There's more that one solution

           

          1. You can place all PDI files to shared network resource with limited access (read-only)

           

          2. You can set a special setting in procbook.ini file:

           

           

           

          [Startup]

           

          ProcessBook=Primary

           

           

           

          In this mode ProcessBook run as only viewer without any design abilities.

            • Re: Restricting user from modifying ProcessBook PDI files.
              hanyong

              Sergey Bannikov

              2. You can set a special setting in procbook.ini file:

              [Startup]

               

              ProcessBook=Primary

               

              In this mode ProcessBook run as only viewer without any design abilities.

               

              Nice Sergey, I never realised there is such a setting. Thanks for sharing.

                • Re: Restricting user from modifying ProcessBook PDI files.
                  Bannikov

                  I wonder that you've never heard about it. Look into online help for ProcessBook (procbook.chm) and search keywork 'Primary'. I think that this keywork is a bit confusing, but it's only keyword

                   

                  ProcessBook—Setting this value equal to PRIMARY allows users on a network to view ProcessBooks, but not change them. The user will have access to the Standard toolbar, including trend displays, but cannot save an ad hoc display.

                   

                  One more thing about it. There's two PROCBOOK.INI files. One in C:\Program Files\PIPC\DAT  (if default location was used during install).  This is global setiing for all users on this computer.

                   

                  Second resides in "C:\Documents and Settings\USERNAME\Application Data\PISystem\PI-ProcessBook\" folder and is USERNAME-specific. With help of this file (if it doesn't exists, you can create a new one) you can provide more sophisticated control over PDI files access.

                   

                  Last note. This is very confusing for users (particulary for new users) when they look at ProcessBook first time when this setting is enabled. Even I myself have stalled some times around simple question - why I can't modify this display at all?

                • Re: Restricting user from modifying ProcessBook PDI files.
                  formerpigeek
                  Hi Sergey, Thanks for the quick response, we tried out the setting and its working fine, I would also like to know if I can completely remove PI ProcessBook menu's (File Menu) and display my custom menu options. Thanks & Regards Kavita
                    • Re: Restricting user from modifying ProcessBook PDI files.
                      Bannikov

                      There's one more alternative:

                       

                       

                      Security

                      Any string or integer value in PROCBOOK.INI can be overriden in the registry. Overrides can be provided in the HKEY_LOCAL_MACHINE\SOFTWARE\PISystem\PI - ProcessBook\Security key. Under that key there is a key for the INI file section. The values are in that section. For example, to override the EnableScreenSaver setting in the STARTUP section of PROCBOOK.INI, a DWORD value EnableScreenSaver with a value of 1 would be created in HKLM\SOFTWARE\PISystem\PI - ProcessBook\Security\Startup.

                       

                      If a value is found in the Security overrides section of the registry, the PROCBOOK.INI files will not be accessed.

                       

                      The PI ProcessBook setup kit does not create these registry keys; it is up to each site administrator to create the keys if they want to override the PROCBOOK.INI settings.

                       

                      About your question:

                       

                      Kavita Enner

                      I would also like to know if I can completely remove PI ProcessBook menu's (File Menu) and display my custom menu options

                       

                      There's how ProcBook stores toolbar configuration ([Startup] section of PROCBOOK.INI file:

                       

                      Toolbar Configuration Entries—Typically the toolbar INI file (PBToolbarConfig.ini) is generated by ProcessBook in the same folder as the private PROCBOOK.INI file, and is persisted there. However, you can assign toolbar configurations to other INI files by setting the entries below (in order of precedence, from first to last):

                       

                      TBFilePath—Location and filename that the user's toolbar configuration data will be persisted (this file must have both read and write access). This will also be the first location looked for when loading the toolbar configuration.

                       

                      UserDefaultTB—Read-only location and filename of a toolbar configuration that is searched for, when the file in TBFilePath is not found. This could be a default company, or group, configuration.

                       

                      PBDefaultTB—Read-only location and filename of a toolbar configuration, used only when the two entries above are not found, and there is no toolbar configuration data persisted in the Windows registry.

                       

                      You  can prepare desired tolbar configuration (by run ProcessBook and use standard menus) and deploy it for all users that requires such customization

                  • Re: Restricting user from modifying ProcessBook PDI files.

                    Use ActiveView on clients where you don't want them to author displays.

                     

                    The thing with the restricting clients from going in to Build mode is they can't build their own local displays, which stunts their own creativity in visualising their process.  You should look to have a central repository where users cannot modify existing displays or better still publish such displays to PI Web Parts/Sharepoint.

                      • Re: Restricting user from modifying ProcessBook PDI files.
                        Bannikov

                        Rhys @ RJK Solutions

                        The thing with the restricting clients from going in to Build mode is they can't build their own local displays, which stunts their own creativity in visualising their process

                         

                        Let's descripe my point of view. It's users and users. The first users (operators) can only watch on existing displays and are very worried if there is any possibility to change their displays. For these users only read-only access can be allowed. We've many requestes from our customer to make ProcessBook read-only.

                         

                        The second users (analytics) can create their own displays or modify existing and they don't need any additional protection because they are wise and powerful.

                         

                        ActiveView is userful, but requires additional management - custom web pages or IIS server or even SharePoint portal. We use ActiveView too, but sometimes we haven't ActiveView available - only ProcessBook was purchased, for example. So we can convert ProcessBook to ActiveView for some people - why not?

                          • Re: Restricting user from modifying ProcessBook PDI files.

                            Sergey Bannikov

                            Let's descripe my point of view. It's users and users. The first users (operators) can only watch on existing displays and are very worried if there is any possibility to change their displays. For these users only read-only access can be allowed. We've many requestes from our customer to make ProcessBook read-only.

                             

                            The second users (analytics) can create their own displays or modify existing and they don't need any additional protection because they are wise and powerful.

                             

                            ActiveView is userful, but requires additional management - custom web pages or IIS server or even SharePoint portal. We use ActiveView too, but sometimes we haven't ActiveView available - only ProcessBook was purchased, for example. So we can convert ProcessBook to ActiveView for some people - why not?

                             

                            I'll add in some of my observations.

                             

                            Operators do want standard, structured displays that they don't have to maintain (much like you get on DCS).  On the flip side, they also like the flexibility to build their own displays when a process does not behave within normal conditions - any displays they build for analysing will then be passed up to see if they should be incorporated in to the standard displays (i.e. Read Only).  I just don't like the idea of an operator sat there in read only mode of ProcessBook when they want to do their own modelling, analysis...after all PI is typically a secondary monitoring system with greater flexibility over DCS.  The DCS is the place that should be tightly locked down.

                             

                            Those type of roles that are constantly analysing data must have access to create their own displays...obviously.

                             

                            Licencing for clients is always an issue, usually there is a better tool for the job but you work within their constraints.  Just get your clients to agree to an Enterprise Agreement with OSIsoft, much better working conditions