Paginator on top of tables #4339

Closed
opened 2025-12-29 18:34:57 +01:00 by adam · 9 comments
Owner

Originally created by @kbsx32 on GitHub (Dec 8, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.9.9

Proposed Functionality

Move or add paginator at top of any tables (e.g. prefixes, ip address, prefix ip addresses)

Use Case

At least there is no search/filter in prefix ip addresses view so the only way to find IP address is to scroll down many pages to find next-page button.

Futhermore, I think it is better to navigate between table pages via page navigator that on the top of page. When it is in bottom of page you have to scroll down all pages to find next-button page until reach object you want

Database Changes

N/A

External Dependencies

N/A

Originally created by @kbsx32 on GitHub (Dec 8, 2020). Originally assigned to: @jeremystretch on GitHub. <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/g/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8 * NetBox version: 2.9.9 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Move or add paginator at top of any tables (e.g. prefixes, ip address, prefix ip addresses) <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case At least there is no search/filter in prefix ip addresses view so the only way to find IP address is to scroll down many pages to find next-page button. Futhermore, I think it is better to navigate between table pages via page navigator that on the top of page. When it is in bottom of page you have to scroll down all pages to find next-button page until reach object you want <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes N/A <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies N/A
adam added the status: acceptedtype: feature labels 2025-12-29 18:34:57 +01:00
adam closed this issue 2025-12-29 18:34:57 +01:00
Author
Owner

@DanSheps commented on GitHub (Dec 8, 2020):

We can look at inclusion for this after the final release of 2.10.

Would you be willing to take this on (I think adding the pagination at the top as well would be good)

@DanSheps commented on GitHub (Dec 8, 2020): We can look at inclusion for this after the final release of 2.10. Would you be willing to take this on (I think adding the pagination at the top as well would be good)
Author
Owner

@jeremystretch commented on GitHub (Dec 21, 2020):

I've tagged this as needs owner, but want to caution that any proposed changes must carefully adjust the UI layout. (Please don't just copy & paste the paginator at the top of the template, leaving a large amount of wasted space.)

@jeremystretch commented on GitHub (Dec 21, 2020): I've tagged this as `needs owner`, but want to caution that any proposed changes must carefully adjust the UI layout. (Please don't just copy & paste the paginator at the top of the template, leaving a large amount of wasted space.)
Author
Owner

@stale[bot] commented on GitHub (Feb 4, 2021):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Feb 4, 2021): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@stale[bot] commented on GitHub (Feb 22, 2021):

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.

@stale[bot] commented on GitHub (Feb 22, 2021): 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.
Author
Owner

@cpmills1975 commented on GitHub (Feb 22, 2021):

Happy to have a go at this if it is re-opened and assigned to me?

@cpmills1975 commented on GitHub (Feb 22, 2021): Happy to have a go at this if it is re-opened and assigned to me?
Author
Owner

@DanSheps commented on GitHub (Feb 23, 2021):

@cpmills1975 Assigned you, feel free to give it a go while heeding the advice the advice given regarding wasted space

@DanSheps commented on GitHub (Feb 23, 2021): @cpmills1975 Assigned you, feel free to give it a go while heeding the advice the advice given regarding wasted space
Author
Owner

@cpmills1975 commented on GitHub (Mar 16, 2021):

So, I've done some work on this and I have what feels like a reasonable solution for the pagination at the top of the table. However, the bottom one troubles me - especially when it appears directly under the table when the side bar is long (device list for example) vs when it appears under the side bar when the sidebar has less search options and appears shorter than the list (interfaces for example).

I've tried to juggle things around a bit such that the pagination is always in line with the right hand side of the table, but it is proving quite difficult to get it to appear in a consistent way.

Digging through the templates and the inspector in Safari, I can see that the page is fundamentally using the Bootstrap grid system. The sidebar is 3 columns wide, but with a minimum and maximum width specified, while the underlying table is nominally 100% wide, but shrunk by the side bar. If I make the table 9 columns wide, not only does it still take up all the remaining space, the page as a whole renders in a more responsive manner on smaller devices (IMO the page doesn't render particularly well on smaller screens as it stands, but I won't go in to that here).

Was structuring the page in this way (with only the sidebar width set and then constrained) a deliberate choice? If it was, can I ask why? Would there be any objections to setting the table to 9 columns wide rather than letting the browser automatically shrink it?

Are any changes to the UI pointless now given the plans to re-think the templates in #5893?

@cpmills1975 commented on GitHub (Mar 16, 2021): So, I've done some work on this and I have what feels like a reasonable solution for the pagination at the top of the table. However, the bottom one troubles me - especially when it appears directly under the table when the side bar is long (device list for example) vs when it appears under the side bar when the sidebar has less search options and appears shorter than the list (interfaces for example). I've tried to juggle things around a bit such that the pagination is always in line with the right hand side of the table, but it is proving quite difficult to get it to appear in a consistent way. Digging through the templates and the inspector in Safari, I can see that the page is fundamentally using the Bootstrap grid system. The sidebar is 3 columns wide, but with a minimum and maximum width specified, while the underlying table is nominally 100% wide, but shrunk by the side bar. If I make the table 9 columns wide, not only does it still take up all the remaining space, the page as a whole renders in a more responsive manner on smaller devices (IMO the page doesn't render particularly well on smaller screens as it stands, but I won't go in to that here). Was structuring the page in this way (with only the sidebar width set and then constrained) a deliberate choice? If it was, can I ask why? Would there be any objections to setting the table to 9 columns wide rather than letting the browser automatically shrink it? Are any changes to the UI pointless now given the plans to re-think the templates in #5893?
Author
Owner

@github-actions[bot] commented on GitHub (Jan 12, 2022):

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. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 12, 2022): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@jeremystretch commented on GitHub (Jan 14, 2022):

This has become much easier to implement since the paginator HTML was tweaked for HTMX-enabled tables under #8057. However, I'm going to tag it for v3.2 so that we can expose the paginator location (top, bottom, or both) as a well-defined user preference (#7759).

@jeremystretch commented on GitHub (Jan 14, 2022): This has become much easier to implement since the paginator HTML was tweaked for HTMX-enabled tables under #8057. However, I'm going to tag it for v3.2 so that we can expose the paginator location (top, bottom, or both) as a well-defined user preference (#7759).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4339