I have a doc with (basically) a Project table rwith several related tables like Tasks, Texts, etc. and different views for Tasks, Texts etc that the user can filter after Project. Problem is, when two users work on the same view, and want to work with different Project filterings - the filter User1 selects is immediately updating the page as seen by User2.
I have seen no other way than making separate versions of the pages for each user - VERY cumbersome when it comes to updating functionality etc.
Any other possibilities?
Or is it on the CODA roadmap to allow for User log-in to dedicated instances of a doc?
Dear @Tellef_Kvifte,
I suggest that you create for each user concerned a page, where you make available a view of the concerned tables specific for this user.
When the user starts filtering / updating the other users will not be distubed and updates can be executed.
One important thing to consider is to structure your tables in a way that when you extract results from tables, that the underlaying info is set with a certain moment in time.
What do I mean, when it’s now 10:00 am and there are 100 chew gums in stock, the sales team might have sold at 11:00 am 60 pcs and no new stock has arrived. This will mean that there are at 11:00 am only 40 pcs in stock.
Hey @Tellef_Kvifte, there is a way to do this, and I hinted at it so many times (e.g. here), but always wanted to publish this as a separate article/guide. Maybe today is the day, and I’ll finally do this later today.
The trick is to introduce a table where each row will be a set of inputs and calculations for a specific user, then base the rest of the doc (filters etc) on that table. I.e. not use canvas controls and formulas at all.
OK here’s a brief way to do this. Set up a table _users with all of your users, and put in an email address column that matches the email they used to sign up: [User], [Email].
Then create a canvas formula to determine the logged in user:
user = _users.Filter(Email=User().Email).First()
Then in your table you want to filter, lets say tasks table, you will want to have a column [Users] with all of the associated users. This can have more than one. Now create a view of that task table - this view will be the ‘main’ view only showing tasks matching the logged in user.
Set the filter condition so that it filters away any row that doesn’t contain the logged in user (canvas formula) in the [Users] column:
thisRow.Assign.Contains(User)
Where User is the corresponding canvas formula. And there you go! Now each user will see the Tasks table filtered to only show their tasks.
1 Like
Got that already - not too difficult. The problem is when each user want their task list first filtered by Project, and two users filter by different Projects at the same time.
In your user table create a column Filtered Project and store the variable for each user’s filter there. Then use the logged in user canvas variable user.[Filtered Project] as the variable for the filter.
Works - but only as long as two users are not using the same table at the same time - ?
By the way - thanks a lot for your time and interest!
I ran into the same issue today after spending the weekend building a system for users at work. My (wrong) assumption was that default behavior would be that different users automatically get different views.
Imagine the surprise I had when I proudly tried to demo the system to my colleague… oops…
Then I looked at the workarounds posted and they kinda work… but the more I thought about it, I fail to see why the default behavior for interactive controls to not be user specific…
2 Likes
@Tellef_Kvifte this is working for me; my user table stores numerous states/variables for the various users and I’m able to build a ux across the doc that is dynamic for each user.
There are some areas where this doesn’t work super well. I have a ‘search’ table that is used across the doc and only one person can be in it at a time, unless I create a separate row for each user, but that gets back to the original problem which you were trying to avoid.
I was thinking, but haven’t implemented/tested yet, that it could be possible to build an automation/button that automatically adds these ‘necessary rows for each user’ upon the addition of a user to the user table… if it was done seemlessly enough it could overcome the fact that its somewhat of a ‘kludge’.
I finally recorded the tutorial on this. FYI for everyone who’s looking for the solution and finding this thread
1 Like
Just stopping by to share that progress has been made on this front!
2 Likes
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.