Dashboard: I can delete database table rows but cannot edit them

[Ali]

Hi,

I've deployed an app on AWS using an RDS MySQL database. I've been trying to use the dashboard to delete and edit rows in database tables. Interestingly, I can delete rows using the dashboard interface but I'm unable to edit them. When I click on a row to access its details and apply changes, everything seems fine, but after hitting "save" and returning to the main table page, I see that none of the changes were applied.

I can both delete and edit rows using Python code. (I achieve this by setting up an endpoint that triggers certain scripts when accessed.)

Any thoughts on what might be causing this issue or how to resolve it?

Thank you,

ali

[Massimo]

No idea. Can you send a minimal model to reproduce? Or perhaps check if there is any error in the js console or in the dashboard.

[Ali]

I've done some further investigation and found that the issue occurs when auth.signature is added to the table definition. Here is an example:

db.define_table('test',

                Field('name'), Field('age', 'integer'), Field('interest'), auth.signature)

Here is the output I get when trying to edit a row:

The dropdown menus corresponding to the created_by and modified_by fields do not display any options (they are always blank). I am not sure if this is expected or not. Nonetheless, as shown in the image above, an error is returned for all the auth.signature fields.

In the browser console, when I try to edit a row in a table with auth.signature, I see the following error:

mtable.js:104 

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'url')
    at mtable.js:104:63

Any suggestions on how to resolve the issue?

Thank you,

-ali

[Ali]

By the way, I've noticed that the issue also occurs locally, where SQLite is being used. This suggests it may not be related to the SQL mentioned in my original message.

[Massimo]

I see the problem. Give me a few days to fix it

[Ali]

Thank you, Massimo.

I also investigated the issue on my end. It looks like the issue stems from the fact that writable is set to False by default for the auth.signature fields.

One could fix the issue by changing the default to True, but then a new problem arises: the auth.signature fields will appear in the forms created based off of the table. One solution I am considering is to create forms manually rather than generating them directly from the table.

Please let me know if you have any thoughts on this approach.

[Massimo DiPierro]

the tricky part here is deciding whether dashboard should allow or not editing fields that are writable=False 

--
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/06f50592-2fe5-40ba-9ab8-62a4255fc3den%40googlegroups.com.

[Ali]

I will be totally fine if the dashboard does not allow fields with writanle=False to be edited. The issue seems to be that, when a field with writable=False exists, no other field can be edited on the dashboard, even if its writable=True. That may be because, during an edit operation, the dashboard sends an updated set of values for 'all' the fields to the server. Does it make sense?

[Ali]

Hi, I was wondering if there’s been any update on this. I’d be happy to provide a minimal example if that would help.

-ali

[Massimo]

I apologize. Fill fix it this week

[Ali]

Could you share if there’s any update on this?

- ali

[Ali]

Hi!

I was wondering if there's any update on this. Here is a snippet taken from previous messages that summarizes the issue:

I will be totally fine if the dashboard does not allow fields with writable=False to be edited. The issue seems to be that, when a field with writable=False exists, no other field can be edited on the dashboard, even if its writable=True. That may be because, during an edit operation, the dashboard sends an updated set of values for 'all' the fields to the server. Does it make sense?

Thank you,

Ali

[Massimo]

Sorry it took so long. Should be fixed now in master. Can you please check and confirm?

[Ali]

Everything is good now! It was such a relief. Thank you!

P.S. I hope an update comes out soon with this change included.

- ali

[Ali]

Hi again,

I had tested the fix on my local. Today, I tested it on the remote and realized the issue still persists there. Here are two key differences between my local and remote environments that might help identify the cause:

1. Locally, I use SQLite; on the remote server, I use MySQL.
2. I installed py4web locally using Git and update through Git too. On the remote server, I installed py4web via the Python command line and update it the same way.

As a reminder, the issue is that I can delete rows through the dashboard, but I cannot edit them—any changes I make don't persist.

- ali

[Massimo DiPierro]

Is there any log in the js console?

To view this discussion visit https://groups.google.com/d/msgid/py4web/c44e412e-3d5c-4c27-a463-17d8c71306fcn%40googlegroups.com.

[Ali]

Yeah, here it is:

[Ali]

I got the console error above in the Microsoft Edge browser. Today, I tried Chrome and Firefox. There is no console error in Chrome, but the edits still don't persist. With Firefox, I got the following error. As with Edge, the issue appears to be related to Vue.js.

- ali

[Massimo]

I suspect you still have an old _dashboard. Your error mentions res.data in _dashboard/static/components/mtable.js but that expression is no longer there.

The problem may still be there but let's make sure first you have the latest code. 

[Ali]

Thank you! Updating the dashboard helped solve the problem.

As I working with the dashboard, however, I noticed a new problem. The dashboard on the remote (which uses MySQL) appears to have issues I try to edit a table with a field of the type "set". 

Here is a screenshot of what I see:

Here is the error in the js console:

Everything is fine on my local that uses SQLite.

- ali

[Massimo]

What is a field of type "set"? Can you provide an example to reproduce?

[Ali]

Sorry for the ambiguity. By "set," I meant a field of type "list:string" or "list:integer".

I tested the issue again today, and everything is working fine now—perhaps my browser cache was not up to date. It is such a relief!

However, while testing, I noticed a minor issue with the dashboard. Suppose there's a field of type "list:string", and a data row is inserted without a value for that field. In this case, the dashboard does not allow you to enter a value for that field. Specifically, when you click on the row ID to view the detailed entry page, the cell corresponding to that field is not editable.

Two related observations:

1. For other field types—e.g., "string"—the dashboard does allow data entry even if the original value is null.

2. If the field value is set to [] instead of null, the cell becomes editable, and everything works as expected.

You can use the following simple table definition to reproduce this behavior:

db.define_table('test', Field('name'), Field('interests', 'list:string'))

Steps to reproduce:

1. Run: db.test.insert(interests=["math", "philosophy"])

2. Open the dashboard. You will be able to enter a value for the name field, as expected.

3. Run: db.test.insert(name="John")

4. Open the dashboard. You will not be able to enter a value for interests for the "John" row.

5. Run: db.test.insert(name="Adam", interests=[])

6. Open the dashboard. You will be able to enter a value for interests for the "Adam" row.

- ali

[Massimo]

Fixed in master

[Ali]

Everything looks good on my local, which uses SQLite. I will test it on my remote, which uses MySQL, once the version 1.20250511.1 is released.