Skip to content
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

Open
wants to merge 13 commits into
base: develop
Choose a base branch
from

Conversation

LHBL2003
Copy link

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.

LHBL2003 and others added 13 commits May 17, 2024 17:39
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 = {
Copy link
Member

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.

Copy link
Author

@LHBL2003 LHBL2003 Dec 9, 2024

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.

Copy link
Author

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": [
Copy link
Member

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?

Copy link
Author

@LHBL2003 LHBL2003 Dec 9, 2024

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.

Copy link
Author

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",
Copy link
Member

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.

Copy link
Author

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.

Copy link
Author

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”.
Copy link
Member

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.

Copy link
Author

@LHBL2003 LHBL2003 Dec 9, 2024

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)

Copy link
Author

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)

@jeremystretch jeremystretch changed the title Patch 3 Closes #16076: Extend PROTECTION_RULES example Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Example for PROTECTION_RULES in WEB UI.
2 participants