View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001437 | Compliance Test Tool (CTT) Unified Architecture | public | 2010-12-10 18:18 | 2013-12-17 22:37 | |
Reporter | Matthias Isele | Assigned To | Matthias Isele | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Summary | 0001437: Monitor Value Change test 5.9.1-Err-013 | ||||
Description | Test creates a monitoreditem of scalar type (int, double...) with index range. | ||||
Tags | No tags attached. | ||||
Files Affected | |||||
related to | 0001443 | closed | Matthias Damm | 10000-004: Services | Compliance issue: CreateMonitoredItems with IndexRange |
|
I reviewed P4 CreateMonitoredItems and this delayed processing of error codes is only partially mentioned, but specifically describes this delayed processing in the context of user access rights. Here's the paragraph: "When a user adds a monitored item that the user is denied read access to, the add operation for the item shall succeed and the bad status Bad_NotReadable or Bad_UserAccessDenied shall be returned in the Publish response. This is the same behaviour for the case where the access rights are changed after the call to CreateMonitoredItem. If the access rights change to read rights, the Server shall start sending data for the MonitoredItem." In addition, Table 66 (part 4, page 68) does show Bad_IndexRangeInvalid as an entry. I understand your viewpoint in that a Node's type/access can change after the call to CreateMonitoredItems, so I am thinking that we should potentially allow for 2 paths: I do think that we need to have this clarified in P4. What are your thoughts? |
|
Table 66 (part 4, page 68) does show Bad_IndexRangeInvalid as an entry. The behaviour should be clarified in part 4. |
|
Added related topic for clarification in part 4 |
|
Changed our mind. |
|
Fixed a long time ago. |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-12-10 18:18 | Matthias Isele | New Issue | |
2010-12-10 18:27 | Matthias Isele | Assigned To | => Nathan Pocock |
2010-12-10 18:27 | Matthias Isele | Status | new => assigned |
2010-12-13 16:42 |
|
Note Added: 0002176 | |
2010-12-13 16:42 |
|
Assigned To | Nathan Pocock => Matthias Isele |
2010-12-13 16:42 |
|
Status | assigned => feedback |
2010-12-13 17:11 | Matthias Isele | Note Added: 0002177 | |
2010-12-14 12:57 | Matthias Isele | Relationship added | related to 0001443 |
2010-12-14 13:03 | Matthias Isele | Note Added: 0002181 | |
2011-03-07 11:53 | Matthias Isele | Assigned To | Matthias Isele => Nathan Pocock |
2011-03-07 11:53 | Matthias Isele | Resolution | open => fixed |
2011-03-07 11:53 | Matthias Isele | Additional Information Updated | |
2011-03-07 11:59 | Matthias Isele | Assigned To | Nathan Pocock => Matthias Isele |
2011-03-07 11:59 | Matthias Isele | Status | feedback => assigned |
2011-03-07 11:59 | Matthias Isele | Resolution | fixed => open |
2011-03-07 11:59 | Matthias Isele | Status | assigned => acknowledged |
2011-03-07 11:59 | Matthias Isele | Additional Information Updated | |
2011-03-14 10:47 | Matthias Isele | Status | acknowledged => resolved |
2011-03-14 10:47 | Matthias Isele | Resolution | open => fixed |
2011-05-24 09:34 | Randy Armstrong | Note Added: 0002761 | |
2011-05-24 09:34 | Randy Armstrong | Status | resolved => assigned |
2013-12-17 22:37 |
|
Status | assigned => closed |
2013-12-17 22:37 |
|
Note Added: 0005220 | |
2014-08-28 14:03 |
|
Category | Implementation Bug => (No Category) |