move missing new visibility spec to the split spec #31
Conversation
markus-zolliker
commented
Apr 28, 2025
markus-zolliker
commented
- keep old secop_specification_draft_wip.rst in candidates
+ keep old secop_specification_draft_wip.rst in candidates
There was a problem hiding this comment.
If you really want to keep this file, please rename it to give it a cut-off date (similar to the other files in candidates).
There was a problem hiding this comment.
i wanted to keep it, in case there are other things not (yet) copied to the split spec. but yes, we should put a date
| hint to the UI for the amount of exposed modules. A visibility of | ||
| "advanced" means that the UI should hide the module for users, but | ||
| show it for experts and advanced users. | ||
| string indicating a hint for UIs for which user roles the module should be |
There was a problem hiding this comment.
(nit, this is indented by 5 spaces not 4)
| A SECoP client SHOULD ignore any value not listed in the last two columns of | ||
| above table. | ||
|
|
||
| :Note: |
| A SECoP client SHOULD ignore any value not listed in the last two columns of the above | ||
| table. | ||
|
|
||
| :Remark: |
There was a problem hiding this comment.
Either also .. note:: or .. adminition:: Remark
| There are redundant possibilities for expressing the same access levels, | ||
| best practice for a SEC node is: | ||
|
|
||
| - avoid explicit "w" on parameters with readonly=true |
There was a problem hiding this comment.
Should this case not be flagged as an error? (I.e. disallowed by the spec)
There was a problem hiding this comment.
What makes the difference between discouraged and disallowed? I think a client should be able to handle this case correctly, even when it is disallowed. There might be different scenarios, where this may happen: there is an old config file using old style visibility, but the framework converts automatically "advanced" to "ww-". Or a visibility on a parameter is set in the code to "ww-", but in the config file readonly is set to true. We may try to handle all these cases in Frappy on the server side, but I think it is not worth the work. Anyway, on the client side the final visibility of a parameter is merged with the visibility of the module - so this case has to be handled on the client side anyway.
