Operators can reach setpoint controls even when their accounts should be read-only. For this groov View configuration, separate the display into a writable page for authorized users and a duplicate restricted page with every tag-writing gadget removed. Follow the write request from the operator’s page to the target tag; the page containing the writable gadget is the control boundary.
Where does the setpoint write start?
The request begins when an operator interacts with a writable gadget in the groov View session. The gadget submits a new value through the configured tag connection. If the page contains no write-capable gadget, that page provides no user-interface path for initiating the write.
| Path element | Reading or observation | Outcome | Next check |
|---|---|---|---|
| Operator session | Identity used to open groov View | Determines which page the user can reach | Check page access |
| Displayed page | Writable or restricted page | Selects the available controls | Inventory the gadgets |
| Page gadget | Read-only display or tag-writing control | Identifies whether a write can originate | Trace its tag binding |
| Tag connection | Configured target and communication state | Carries the requested value | Observe the target tag |
| Target tag | Value before and after the action | Confirms whether the write completed | Compare against the requested value |
This separates two different controls: authenticating a user and authorizing a particular write. The described solution controls which write controls a user receives. It does not establish a separate credential challenge for every setpoint change.
Does the physical data path work?
Layer one first. Before diagnosing page permissions, verify that the operator station can load the intended page and receive current tag values. A failed link, unavailable HMI service, or broken tag connection can make a writable control appear restricted when the actual problem is loss of communication.
- Open the page from the operator station and confirm that the session remains connected.
- Observe a live value whose normal process variation can be independently checked.
- Compare the displayed value with the value at the tag source.
- If the values do not track, repair the physical and communication path before testing access control.
- If reads work, continue to the page and gadget checks.
| Network item | Value to record | Interpretation |
|---|---|---|
| groov View address | Address used by the tested client | Confirms that both user classes connect to the same intended system |
| Service port | Port from the deployed configuration | Confirms that the test follows the production service path |
| Tag target address | Target shown in the configured tag connection | Identifies the endpoint that receives the setpoint |
| Observation time | Timestamp recorded for the test | Correlates the operator action with the target value change |
Read success proves that part of the route is operating, but it does not prove that the user has or lacks write access. Continue by inspecting the controls delivered to that user.
Can the restricted user reach a writable page?
Log in as the restricted user and enumerate every page reachable through menus, buttons, links, saved browser locations, and normal navigation. The decisive reading is whether that user can open any page containing a tag-writing gadget.
| Observation | Meaning | Action |
|---|---|---|
| Only the restricted duplicate is reachable | The page split is operating as intended | Inspect that page for residual write gadgets |
| The writable page is reachable | The page boundary is incomplete | Correct page exposure before testing tag writes |
| No page loads | This is a session or communication fault | Return to the physical data-path check |
| Navigation differs between sessions | User-specific page delivery is active | Verify every alternate navigation route |
A menu that omits the writable page is not enough if the same user can still reach that page by another route. Test actual reachability with the same account and client conditions used by the operator.
Which gadgets can issue a tag write?
Inventory the original writable page before duplicating it. Classify each gadget by behavior, not by its label or appearance. A numeric entry field, command button, selector, or other interactive object may write a tag. A displayed process value may be read-only. Inspect each gadget’s binding and action configuration to decide which class it belongs to.
| Gadget behavior | Writable page | Restricted page |
|---|---|---|
| Displays a tag value without an input action | Keep when required | Keep when required |
| Accepts a setpoint value | Keep for authorized users | Remove |
| Issues a command that writes a tag | Keep only when required | Remove |
| Navigates to another page | Check destination | Keep only if the destination is also restricted |
Remove write gadgets from the restricted duplicate rather than covering them, moving them off-screen, or relying on a visual label such as “read only.” The object configuration, not its appearance, determines whether it can send a value.
Does page separation provide the required boundary?
Page separation meets the stated requirement when restricted operators receive only pages without write gadgets and cannot reach a writable page. It is a user-interface restriction: it removes the normal groov View control that originates the write.
Decide whether that boundary matches the risk. If the requirement is specifically “operators must not write setpoints from their groov View pages,” the duplicate-page method addresses it. If the requirement is server-side authorization against every possible client or write path, page design alone is not proof of that control. Test other configured interfaces separately and apply write authorization at the system that owns the tag where such protection is required.
Recurring failures include leaving one command gadget on the restricted page, copying later edits from the writable page into the restricted version, exposing the writable page through secondary navigation, and testing with an administrator session instead of the restricted account. Treat the two pages as separate controlled configurations after duplication.
How should the restriction be implemented and tested?
- Identify the existing page that contains all required setpoint and command gadgets.
- Designate that page for users who are permitted to write.
- Duplicate the page for users who must not write.
- Remove every gadget from the duplicate that can write to a tag. Retain only required read-only displays and safe navigation.
- Review every navigation object on the restricted page and remove routes to writable pages.
- Open a restricted-user session and confirm that only the intended restricted pages are reachable.
- Record each tested target tag’s initial value. Exercise every remaining interactive gadget and confirm that none changes a target value.
- Open the authorized page with a write-authorized session, issue one controlled setpoint change, and confirm that the intended target tag receives the requested value.
Use separate sessions for the two user classes so cached navigation or an already authenticated privileged session does not invalidate the result. Record the user class, page, gadget, target tag, value before the test, requested value, value after the test, and observation time.
FAQ
Can groov View require privileges for each individual setpoint write?
The described configuration uses separate pages instead of a per-write credential challenge: authorized users receive the page with write gadgets, while restricted users receive a duplicate with those gadgets removed.
Does hiding a setpoint gadget make the page read-only?
No. Remove every tag-writing gadget from the restricted duplicate and test all navigation routes. A visual change does not establish that the underlying write action is absent.
Can I verify that the restricted page blocks setpoint changes?
Log in as the restricted user, visit every reachable page, exercise every interactive gadget, and confirm that no target tag changes. Then use the authorized page to make one controlled setpoint change and verify that only the intended tag receives the requested value.