-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closes #16076: Extend PROTECTION_RULES
example
#18033
base: develop
Are you sure you want to change the base?
Conversation
Issues to change the documentation netbox-community#16076 PROTECTION_RULES extended by an example of what works in the WEB UI.
Revised after suggestion by jeremystretch
Image inserted in code area
Image uploaded as an attachment so that it has an image ID.
…ration-History-Protection-rules-Example.png Rename
…rotection-rules-Example.png to Configuration-History-Protection-rules-Example.png Rename
Images netbox UI path specification.
|
||
```python | ||
PROTECTION_RULES = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no reason to remove this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the example is not well suited or not well described for someone who deals with the topic.
If I understand it correctly, it mixes 3 complexities together.
Example: The site can only be deleted if the status is: decommissioning.
Notation for Configuration.py file:
PROTECTION_RULES = {
‘dcim.site": [
{
‘status": {
‘eq": ’decommissioning’
}
},
]
}
Notation for web frontend:
‘dcim.site": [
{
‘status": {
‘eq": ’decommissioning’
}
}
]
Notation for Configuration.py with further validation of custom plugins:
PROTECTION_RULES = {
‘dcim.site": [
{
‘status": {
‘eq": ’decommissioning’
}
},
‘my_plugin.validators.Validator1’,
]
}
The problem with the original example is that it does not work out of the box.
Only after many conversations do you find out what is too much.
‘my_plugin.validators.Validator1’,:
Does not work at all for beginners. It is something for advanced users.
Result: An example with this line should be listed separately. As it prevents the part from not working that would always work.
PROTECTION_RULES = {:
Where does it say that this must be omitted in the web frontend? After being the community told that you can insert this example into the web frontend, it does not work because ‘PROTECTION_RULES = {’ must be omitted. But as a beginner you don't know that.
Result:: If not here, then it must be written elsewhere that the outermost bracket in the web front end must be omitted. Otherwise it won't work either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an idea,
in the chapter ‘Dynamic Configuration Parameter’ I would like to point out that the outer bracket e.g. PROTECTION_RULES = { ..} is relevant within the Configuration.py. In the web frontend, however, this should be removed from the examples. As the parameter in the web front end already represents this.
Would that be ok?
|
||
```python | ||
PROTECTION_RULES = { | ||
"dcim.site": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change the object type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes ok you could leave it at Site. But I think the example is much more interesting for devices.
It is only changed because I had copied my working example from the webfrontent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an idea, I will reverse this example and integrate the variant for Device. Then you can see how to integrate multiple validations.
If that's OK?
{ | ||
"status": { | ||
"eq": "decommissioning" | ||
} | ||
}, | ||
"my_plugin.validators.Validator1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no reason to remove this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above. In my opinion, this should be a separate example, because a beginner is doomed to failure. Because it will never work unless he knows what this line means and what needs to be done for it. I still wouldn't know, because it's too much for the first step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I have an idea. I will undo this and create a hint text that you should leave out this line for the entry. Can you give me a short description of this line so that beginners can understand it better?
Then I would describe the meaning of this line.
Something like: This line is used to integrate a validation of its own plugin. Perhaps also a link to the topic?
@@ -94,17 +94,17 @@ The following colors are supported: | |||
|
|||
!!! tip "Dynamic Configuration Parameter" | |||
|
|||
This is a mapping of models to [custom validators](../customization/custom-validation.md) against which an object is evaluated immediately prior to its deletion. If validation fails, the object is not deleted. An example is provided below: | |||
This is a mapping of models to [custom validators](../customization/custom-validation.md) against which an object is evaluated immediately prior to its deletion. If validation fails, the object is not deleted. The configuration can be carried out in the menu under “System/Configuration History/Custom validators”. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The configuration can be carried out in the menu under “System/Configuration History/Custom validators”.
This is implied by the "dynamic configuration parameter" note above, which appears on many similar parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I hadn't understood the connection between the tip.
!!! tip "Dynamic Configuration Parameter"
Because there is no link to the other md file where the topic was described.
https://demo.netbox.dev/static/docs/configuration/#dynamic-configuration-parameters
It was only through your comment and Google that I found the connection again.
If there was a link to dynamic-configuration-parameters, you could probably understand it better.
I would like to adapt the tip like this:
!!! tip [
Dynamic Configuration Parameter](./index.md#dynamic-configuration-parameters)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it ok if I adjust all these tips?
Before: !!! tip ‘Dynamic Configuration Parameter’
After: !!! tip [
Dynamic Configuration Parameter](./index.md#dynamic-configuration-parameters)
Issues to change the documentation
#16076
Describes how to configure the PROTECTION_RULES as a user via the WEB UI.
Fixes: #16076
The PR was already set some time ago, but it stalled several times. This time without pictures because I had embedded them incorrectly several times.