starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Show markdown in full height for custom script pages #10682

New Issue
Closed
opened 2025-12-29 21:34:40 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:34:40 +01:00
Owner
Copy Link

Originally created by @mhdask on GitHub (Jan 22, 2025).

NetBox version

v4.1.9

Feature type

Change to existing functionality

Proposed functionality

Markdown presentation was changed in #17237, clamping all rendered markdown to a max height of 200px.
When using markdown to create tables in script logging, this max height is easily exceeded, resulting in clamped tables that you have to scroll through, kind of defeating the purpose of the table in the first place - An easy overview.

Can the custom script pages be modified so that markdown does not get clamped in the context of custom scripts?

Use case

Sometimes the full markdown is desired, instead of a clamped version, e.g. for tables creating an overview of something

Database changes

None, as far as I know

External dependencies

None, as far as I know

Originally created by @mhdask on GitHub (Jan 22, 2025). ### NetBox version v4.1.9 ### Feature type Change to existing functionality ### Proposed functionality Markdown presentation was changed in #17237, clamping all rendered markdown to a max height of 200px. When using markdown to create tables in script logging, this max height is easily exceeded, resulting in clamped tables that you have to scroll through, kind of defeating the purpose of the table in the first place - An easy overview. Can the custom script pages be modified so that markdown does not get clamped in the context of custom scripts? ### Use case Sometimes the full markdown is desired, instead of a clamped version, e.g. for tables creating an overview of something ### Database changes None, as far as I know ### External dependencies None, as far as I know
adam added the type: featurestatus: needs ownerpending closurecomplexity: medium labels 2025-12-29 21:34:40 +01:00
adam closed this issue 2025-12-29 21:34:41 +01:00
adam commented 2025-12-29 21:34:41 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Jan 23, 2025):

I think this is a good suggestions, but implementation can go any of a few different ways.

One option might be to add another filter similar to render_markdown, e.g. render_markdown_clamped, which appends a different (or additional) class to rendered-markdown which applies the clamping style. This would mean templates would have to be reworked to use the appropriate filters accordingly.

Another way would be to have a button or control on markdown fields to toggle the clamping on and off. With this approach, there's a further question of whether the behavior last requested should be persistent and apply upon reload of the page, or should it be a purely temporary override similar to the bottom-right resize handle on a textarea? And if persistent (i.e. with a cookie or session variable), should it apply to all markdown fields, or just the one directly clicked on?

Or should the option be a global preference that applies to all markdown fields throughout the app?

I'd like to see some further details of what this would ideally look like when implemented.

@bctiemann commented on GitHub (Jan 23, 2025): I think this is a good suggestions, but implementation can go any of a few different ways. One option might be to add another filter similar to `render_markdown`, e.g. `render_markdown_clamped`, which appends a different (or additional) class to `rendered-markdown` which applies the clamping style. This would mean templates would have to be reworked to use the appropriate filters accordingly. Another way would be to have a button or control on markdown fields to toggle the clamping on and off. With this approach, there's a further question of whether the behavior last requested should be persistent and apply upon reload of the page, or should it be a purely temporary override similar to the bottom-right resize handle on a textarea? And if persistent (i.e. with a cookie or session variable), should it apply to all markdown fields, or just the one directly clicked on? Or should the option be a global preference that applies to all markdown fields throughout the app? I'd like to see some further details of what this would ideally look like when implemented.
adam commented 2025-12-29 21:34:42 +01:00
Author
Owner
Copy Link

@mhdask commented on GitHub (Jan 24, 2025):

Hmm, for my specific usecase, it should be able to be controlled within the custom script, i.e. when you use the logging (self.log_warning, etc.) you could specify whether the text should be clamped or not.

@mhdask commented on GitHub (Jan 24, 2025): Hmm, for my specific usecase, it should be able to be controlled within the custom script, i.e. when you use the logging (self.log_warning, etc.) you could specify whether the text should be clamped or not.
adam commented 2025-12-29 21:34:42 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 1, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Feb 1, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:34:42 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Feb 4, 2025):

I'm not sure exactly what that would look like. Could you provide some pseudocode or an example usage of self.log_warning the way you would want to use it? Remembering of course that And (probably more importantly) is this something that would be applied across the whole product, or is this specific to custom scripts? Is it a choice made by a developer interacting with code, or is this something controlled by end users?

I want to be sure this is a well-thought-through feature that doesn't negatively affect things beyond the narrow scope of the immediate need. From looking at the code it seems like this is maybe only to do with script results, in which case maybe only in script output pages we should use a custom CSS class to avoid clamping the output, thus avoiding changing clamping behavior all throughout NetBox?

If that's the case please adjust the FR title/description accordingly, since that will make it easier to triage and estimate.

@bctiemann commented on GitHub (Feb 4, 2025): I'm not sure exactly what that would look like. Could you provide some pseudocode or an example usage of `self.log_warning` the way you would want to use it? Remembering of course that And (probably more importantly) is this something that would be applied across the whole product, or is this specific to custom scripts? Is it a choice made by a developer interacting with code, or is this something controlled by end users? I want to be sure this is a well-thought-through feature that doesn't negatively affect things beyond the narrow scope of the immediate need. From looking at the code it seems like this is maybe _only_ to do with script results, in which case maybe _only_ in script output pages we should use a custom CSS class to avoid clamping the output, thus avoiding changing clamping behavior all throughout NetBox? If that's the case please adjust the FR title/description accordingly, since that will make it easier to triage and estimate.
adam commented 2025-12-29 21:34:43 +01:00
Author
Owner
Copy Link

@mhdask commented on GitHub (Feb 5, 2025):

I adjusted the FR title, and description accordingly - I agree that it could make sense to only implement this to have an effect for custom scripts, ie. either by custom CSS classes, or ways of controlling it through the logging function.

I think the custom CSS classes would be the easiest way, however, I do not know how that affects the current implementation of render_markdown()

@mhdask commented on GitHub (Feb 5, 2025): I adjusted the FR title, and description accordingly - I agree that it could make sense to only implement this to have an effect for custom scripts, ie. either by custom CSS classes, or ways of controlling it through the logging function. I think the custom CSS classes would be the easiest way, however, I do not know how that affects the current implementation of `render_markdown()`
adam commented 2025-12-29 21:34:43 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 12, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 12, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md).
adam commented 2025-12-29 21:34:43 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 12, 2025):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 12, 2025): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: medium pending closure status: needs owner type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10682
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?