Making the User Table readonly messed up my application

[offbase-solutions]

My use case requires users to connect to a REST Api service using a session token, the session token is passed in the header to the rest api.

My Implementation

1. There is a "sessionToken" field in the user table for the external api service.
2. This "sessionToken" is passed to the rest api via the header in the API Service definition, via the "Current User" bindings
3. This "sessionToken" is refreshed by the user clicking a "Connect to Service" button on a page named "Session"
4. "Session" page is the home page for the application
5. If session is valid, user can continue to the application, if not click the "Connect to Service" button to get a new session which is then updates the "sessionToken" field.

Budibase Update Issues

1. The new updates prevents the User table from being updated, so "sessionToken" field is now readonly
2. I could possibly store the new session token in state, but when I checked "State" is not available in the bindings for the Service definition.

Note
The session cannot be passed via querystring to the API endpoints, so that will not work.

Reverting to a previous version from 2.11.9 to 2.10.10 didn't help, internal user table still remained as readonly.

I am stumped, can anybody(Budibase staff included) suggest a workaround for this scenario.

Regards

[MikeYates]

Following, facing same issue although not exactly but relied on the user table column as well. Have not found a solution yet

[aptkingston]

@offbase-solutions your application should continue to work - we didn't disable being able to write to the user table. Any existing columns in your users table can still be updated via apps. The only change is that you cannot make any further schema changes to the users table going forward, because we've introduced a "user" column type as the replacement.

You cannot edit data in the users table manually via the data section either, but like I said - any apps can continue to write to the users table and update your custom columns.

Could you explain how your app is broken? You will still be able to write the sessionToken value to your users.

[MikeYates]

Hey @aptkingston its a cool update, but how do we bind custom data that is related to the app user? I did manage to find a work around but it's an extra hassle even though works flawlesly. I just think a very important feature was removed.

To be more exact: In my app I would have a column in user table called business_id that identifies which business a user is in, so that I can filter data across my app according to their business_id. I think some people would need this in their app?

[aptkingston]

Hi @MikeYates. You just basically invert the logic to work with the user column type. So instead of having a business_id field in the user table, you would add a user column to the business table instead. Then you can filter the business table by the current user ID to get the row relating to the app user.

[andyburgessmd]

@aptkingston this still doesn't really work for a lot of use cases, I'll try to also give an example....
I have a table called assets which has a name (string), a location (string) and an owner (user).
In the user table I had a field called location so each user could be assigned to a location, but they may not be the owner of any assets.
We could previously run a query on assets where location equals Current User.location and get a list of the assets in that location.

So imagining this is a new application, how do we do create that now, without the ability to extend the user object?

[MikeYates]

@andyburgessmd same issue with me. Although I found a work around.

For your case, you'll need to create a table. First column is the location name, second is the user assign to it (best use the user _id), second column is another user assign to it, so on and so forth. Down side is, you will have to create a column for every user, and a new row on this table is the location.

Next thing is, on every page you need data filtered based on location, add a data provider with data source being the table you just made. Filter it based on the user _id, add a repeater to that data provider, another down side all data need filtered has to be nested under that repeater.

Then on any table you want to show to front end, filter it from the repeater data _id

That way, your data shown will only show based on location that is related to the user.

[andyburgessmd]

Thanks @MikeYates, quite the workaround.
Hoping for something a bit more straightforward from Budibase.

[JCV67]

I had photo, employee number, and other columns in the users table. Now I cannot update those fields.

[ConorWebb96]

Hey @offbase-solutions, @JCV67, @andyburgessmd,

A modification has been implemented to enhance the functionality of legacy apps, enabling you to edit and alter the user's table just as you could before the last release. You can locate the commit for this change here. Once it's merged and a new release is rolled out, you will regain the same capability to amend and modify the users table in all existing applications, just as you could previously.

[andyburgessmd]

@ConorWebb96 only for legacy apps? Is there any advice on how we could have similar functionality in new apps?

[aptkingston]

All existing apps will work as they always have, so there won't be any changes. Going forwards we're encouraging use of the user-type column which is the replacement for this feature. We've just kept user table columns available for existing apps to ensure that any apps already heavily using this feature aren't forced to migrate over to the new user column feature.

I've just rollout out this change, so you should now see the users table as editable again in all your apps.

[andyburgessmd]

@aptkingston but how do we extend users with additional properties using the new user column that we are currently doing in the user table?

[offbase-solutions]

Ok, I have checked, whilst new columns cannot be added, the values in the Users table can be updated using an edit form, automation or external rest api.

[aptkingston]

@andyburgessmd you simply just store a user column in another table, rather than an extra column alongside the user. If it's just metadata that you want to store, and no related rows, then you could create your own "user metadata" table if you like, and store everything there. Then just add a user column to that table to, so the metadata is associated with a certain user.

For an example with relationships, if you had a Tasks table you might have previously created a relationship from the user table to the tasks table. The way to do that with the new user-type column is to add a column to your tasks table instead, of this user type, then assign a user to each task. If you wanted to get the current user tasks, you would just filter the tasks table so that the user column equals the current user ID.