Hi, I got an edit screen with a choice component, that successfully updates the column but also I need to update that choice in another table/column…
For that I resorted to the “On submit” in the edit screen. An action to set column values.
The problem is that the on submit action does not update the last user choice, just the previous and I have to enter again into the edit screen and clic send in order to update the another table/column…
I’m a bit confused. What exactly are you looking to update? Can you show us your data model?
I have the users table and the operators/clients table. For reasons that don’t matter, users are stored in both tables. What is happening is that when I edit the value of a column for an operator through the edit screen, I want certain data to also be updated in the users table when I press Submit. I am doing this using the set column values instruction on the users table, and I trigger it in the “on submit” property of the edit screen.
The problem with this is that it is not updating correctly in the users table.
Let me give an example:
If I edit the user Robert and change his role from Client to Administrator, when I press Submit, it changes correctly in the operators table but not in the users table. If I edit the same user again and press Submit again, only then does it update correctly in the users table.
What I think is happening is that the on submit property is not taking the new values I just entered when executing the set column values on the users table. Unfortunately, there is no command in Glide called “Save record” to force the save BEFORE doing the set column values…
I hope I explained myself better. Thanks.
Hola Matias,
If I followed your problem well, the solution isn’t possible.
The roles cannot be changed from your APP, it must be done using GDE directly.
Here you can read further details https://community.glideapps.com/t/cannot-write-info-to-role-column-in-user-table/
Saludos!
But the roles are created by me, the programmer, in a table external to the users table… why couldn’t a user change the data of other users within the users table?
So the role columns mentioned here are not used as Glide’s role in user profiles setup, is that correct?
The roles, there are related in the Users table yes
I mean this.
Yes is that, I have used roles to set visibility conditions…
So this point stands from @gvalero 's comment.
Creating psuedo roles compared to using Glide’s built in Role functionality are two similar but quite different things and serve different primary purposes. One can control visibility and filtering, but cannot secure data. The other can be used to control visibilty/filtering as well as secure data. However, with true Glide Role functionality, as defined in the documentation, a user’s role cannot be changed via the app for security reasons. It’s important to understand the differences so we can best guide you.
Based on what you have said, it does appear to sound like you are not using the true built in Glide Role functionality, simply because you are in fact able to change a role after the second attempt. Glide Role functionality is defined by setting the role column in the user profile configuration screen. I think you are instead using pseudo roles which do not provide the same data security that true role functionality would,but could still be used for visibility/filtering. In that case you can in fact change the role, since it’s not tied to any data security functionality.
If the above is true, I feel like you could be approaching this in a different way. It’s not good practice to duplicate data if you don’t need to. I feel that the reasons for doing it do matter to better understand your database setup. I suspect you may have a private user table with row owners and another public operator table without row owners. If set up correctly, you should only need to write data to a single table, and then you can rely on computed columns such as a relation and lookup to bring that same data into the other table. This would eliminate any need for an On Submit Set Column action.
Of course, you may have legitimate reasons for doing it the way you are. It just helps if we can understand those reasons as well. Just want to make sure we aren’t trying to solve the wrong problem.
I realize that On Submit is not working as one would expect, but at the same time, there are a lot of nuances to On Submit (as far as which record you are actually attached to, and when previously changed data becomes available to any subsequent actions) that are not easily understood and it’s best to be aware of any potential gotchas when using it.
The conversation may have gotten off track simply because you mentioned changing roles, but it’s also important for us to understand your setup and if you are using true Role functionality.
