Problem with _dashboard after updating to latest master from github

[David Manns]

I just updated my development environment to lastest py4web, I was running a September version.

_dashboard won't open the databases section of my app (screen shot of the error attached).

I must be missing something obvious - I find make_safe() defined in _dashboard/utils.py and _dashboard/__init__.py has from ./utils import *

[David Manns]

Sorry, "from .utils import *" . 

If I breakpoint at __init__ line 393, I find everything prior to make_safe defined in utils is defined, i.e. up through create_app, but make_safe and following are not?? This seems bizarre

[David Manns]

As a side note, _dashboard/utils.py seems to be missing .import datetime

And make no longer seems to have "make requirements"

[David Manns]

in _dashboard/utils:

added import datetime at line 20

added "make_safe" to __all__

_dashboard now seems to be working.

import gzip

import logging

import os

import re

import shutil

import subprocess

import tarfile

import datetime

__all__ = (

"safe_join",

"list_dir",

"recursive_unlink",

"tar",

"untar",

"pack",

"unpack",

"create_app",

"make_safe"

)

[David Manns]

Probably run, get_commits, get_branches, and is_git_repo also need to be included in __all__

[Nico Zanferrari]

Thank you David,

I've just made a PR to fix it (#1014 Dashboard app: fix errors from utils and no.css ). This also fix some minor syntax problem on no.css.

I'm working on the Dashboard app to make it more standard, and Massimo liked some of my suggestions. But he spot some problems and preferred to revert some pieces.

I'm also trying to improve the Dashboard app to use themes - stay tuned ;-)

Cheers,

Nico

--
You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/py4web/679fadd3-e480-448a-b14c-ce8e7669eb0cn%40googlegroups.com.

[Hadi Zarkoob]

Thank you, Nico, for your work on improving the dashboard app. It is such a handy app. I wanted to share a few features I appreciated in the old and new versions.

Old version:

1. All rows had a uniform height, similar to standard database interfaces.

2. Reference fields were clickable, allowing users to navigate directly to the corresponding row.

New version:

1. The row order is now saved in the URL, which allows users to refresh the page without losing their custom ordering.

2. The in-dashboard editing interface looks more polished.

I hope that as many of these features as possible can be retained or expanded upon in future releases.

Thank you again!

Hadi

[Massimo DiPierro]

100% we should restore old version 1 & 2 if they are broken. Will test it and get it done today or tomorrow.

[Nico Zanferrari]

Hello Hadi, thank you.

I've just made  https://github.com/web2py/py4web/pull/1019  that should resolve:

1. Reference fields were clickable, allowing users to navigate directly to the corresponding row.

Please test it -I'm not so confident it works fine in every situation.

The other issue with the new version ("All rows had a uniform height, similar to standard database interfaces.") is not so clear to me. Could you provide us with a couple of screenshots showing the differences?

Cheers,

Nico

To view this discussion visit https://groups.google.com/d/msgid/py4web/e513422e-a17e-4ff6-9692-7f08cc3fa45bn%40googlegroups.com.

[Massimo DiPierro]

Thanks Nico. I tested and merged with a minor change.

[Hadi Zarkoob]

Thank you, Nico and Massimo. I tried a few tables, and the reference field hyperlinks all worked properly!

As for the uniformity of row heights, please find a screenshot below. As shown, row heights are determined by the content rather than following a fixed value. The standard database interface has all rows at the same height. That will lead to trimming of long content, but that is fine because users can always click the details button to see the full content.

By the way, there’s one issue regarding row ordering: when you click a row header for the first time, it has no effect. You need to click twice to get the order reversed, which is not very user-friendly.  

Thank you very much!

Hadi

[Nico Zanferrari]

Thank you Hadi, now it's clear. Everyone can simply test it by selecting the Showcase app and then Database -> db.thing

This uniformity of row heights could be forced by changing the dbadmin.html to:

[[extend "layout.html"]]

<style>

/* Prevent word wrapping in grid cells - truncate with ellipsis instead */

.grid-td {

max-width: 300px !important;

overflow: hidden !important;

text-overflow: ellipsis !important;

white-space: nowrap !important;

}

</style>

<h2>Table "[[=table_name]]"</h2>

[[=grid]]

It works, but I'm not sure this is the right solution... Does someone has better ideas?

About the row ordering working only at a second click, unfortunately I cannot reproduce it. Please report the OS and browser you're using.

Nico

To view this discussion visit https://groups.google.com/d/msgid/py4web/a503010e-cc85-468b-8b1b-6b753da2ddc1n%40googlegroups.com.

[Massimo DiPierro]

Incorporated in the dashboard style. Thanks Nico.

[Hadi Zarkoob]

Thank you, Nico and Massimo. I just verified that the issue with uniform row heights has been resolved!

Nico, I think I understand where the uncertainty about row ordering comes from. Here’s a more detailed explanation.

When a user first opens a table, the rows are sorted in ascending order by the row index. If they click the index header, the string ?orderby={table_name}.id is added to the URL, but the order does not actually change. When they click the index header a second time, the string ?orderby=~{table_name}.id is added to the URL and the order is reversed. From that point on, clicking the header continues to toggle both the URL and the row order, which is the expected behavior. The problem only occurs the very first time a table is opened.

I would normally categorize this as a minor issue, but it’s worth noting that clicking the index header is a very common action, since users often open a table specifically to see the latest entries.

One possible quick and easy solution would be to update the code that handles header clicks as follows: treat a URL without any orderby parameter exactly the same way as a URL with ?orderby={table_name}.id. In practice, this could simply mean replacing a URL without an orderby parameter with the same URL with ?orderby={table_name}.id appended before any downstream analysis is performed.

By the way, here’s another enhancement suggestion regarding the table interface in the dashboard.

It’s common for users to want to scroll all the way to the right to see the columns at the end. This would be much easier if the horizontal (overflow-x) scrollbar were visible as soon as a table is opened, without requiring users to first scroll down to the bottom. Please see the two screenshots below.

It looks like this shouldn’t be too difficult to implement, since there is a good amount of unused real estate at the top of the table pages (yellow boxes in the first screenshot). For example, one could reduce some top margins and paddings, reduce the padding at the top and bottom of each row (td elements), or even reduce the number of rows per page from 15 to 10.

Current table interface:

Suggested table interface:

Thank you,

Hadi

[Hadi Zarkoob]

It looks like the two screenshots weren’t properly included in my previous message. I’ll try again here.  

Current table interface:

Suggested table interface:

[Dave S]

On Sunday, January 25, 2026 at 3:26:32 PM UTC-8 Hadi Zarkoob wrote:

[...]

It’s common for users to want to scroll all the way to the right to see the columns at the end. This would be much easier if the horizontal (overflow-x) scrollbar were visible as soon as a table is opened, without requiring users to first scroll down to the bottom. 

I had that complaint about admin in web2py.

/dps

 

[Hadi Zarkoob]

Thank you, Dave.

I have some good news. Based on further investigation, inspired by the earlier dashboard version, it turns out there’s a much simpler solution. Right now, overflow-x is set to hidden on the body and to auto on .grid-table-wrapper. We can just remove both of these settings. That way, the horizontal scrollbar will appear at the bottom of the page whenever the content is too wide, just like in the old dashboard implementation!

Hadi

[Nico Zanferrari]

This thread is becoming huge and difficult to follow. Please open new threads for different arguments ;-)

• About row ordering, I've created https://github.com/web2py/py4web/issues/1021 = On the dbadmin interface of the dashboard app, row ordering works only at second click #1021 - so that we can follow it better.
• About db scrolling, since you've found a simple solution, would you mind creating a PR or at least exactly describe the proposed code change?

Cheers,

Nico

--

You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/py4web/294f6cc2-540c-4014-8bb4-07f56fdbdd42n%40googlegroups.com.

[Hadi Zarkoob]

Thank you, Nico, for helping streamline the processes—two great ideas! I’ve updated the issue regarding row ordering, and I’ve created a PR for the enhanced table interface.  

Hadi