Howdy, @jenaymarbury: You’ve noticed something that a lot of folks who are new to Bubble miss: Objects that are created by a User have a built-in, implied relationship to the creating User. (Because those objects have the User in their “Created by” field.)
So for some applications, this is all one needs to “associate” certain created objects with their “owner”.
In your case, you have a “Task” object that, for tasks explicitly created by the User, you can get the list of all that User’s tasks by “Do a search for… Tasks” (with constraint Created by = that user (who, in the context of being logged in is “Current User”).
Now, that built-in facility (as you note) breaks down if there are other ways of creating a new Task. Tasks created by the system (e.g., in a workflow that the User did not initiate) have no Creator.
Similarly, there’s no reason that another User or you the administrator couldn’t create a Task and then assign it to another User or “suggest” it to another User.
[One additional observation: Note that the Creator field isn’t a text field. It is actually of User type. One doesn’t have to do a lookup of which User has that unique ID. This points us toward the proper “Bubble way” to associate an object with a User (or indeed associating any “thing” with any other “thing”).]
In your case, you essentially have a need for Tasks, no matter how created, to be assigned to that User.
One way to do this is as follows:
Perhaps the User object should have a list of Tasks on it. (In your database view, you create a new field on the User object called “Tasks” or “Assigned Tasks” or “Current Tasks” or whatever you want to call it. This will be of type Task and it will be a list (check the box for “is a list”.)
When the User does something to create a new Task, in your workflow you (1) Create a new thing (of type Task of course with whatever fields filled out as appropriate) then (2) Add that new task to the User’s list of tasks (that is “Make Changes to a thing” (what thing? The User. Field to change? Tasks add item Results of step 1 (the Task we just created).
Now you always know the Tasks assigned to the User as “User’s Tasks”. User’s Tasks is a list of objects of type Task.
That’s one way. An explicit way. You could also have an implicit model. You could instead (or also) have field on the Task object for “Users” or “Assigned Users” (which could be lists of User type) or it could simply be “User” or “Owner” or “Assignee” (which might be simply an individual User object, rather than a list).
So, when a Task is created you change this field to include the User to whom the Task should be assigned.
Then, Tasks that are associated with the User can always be accessed by “Do a Search for… Tasks” (constraint field User = the User in question or [in the case of a list for example] field Assigned Users contains the User in question.
There’s no need for cookies and such. And don’t make the mistake of thinking of Users as only being accessible by their unique ID text fields. A User is a data object. You don’t store the uid of the User (a text) on the Task, for example, you literally store the User (an object of User type) on the Task.
Back to the UI you are proposing: You should think about whether or not it’s a good idea to let not-logged-in users actually create tasks in your system. Why not just have the create_task page require the user to be logged in? That page can of course simply display the login dialog when Current User is not logged in and then function normally when Current User is logged in.
If you do decide that you need to do things as you describe, I describe a method for doing this in the following post reply. You’ll see that there are a bunch of things you have to handle if your login system allows oAuth logins and it’s rather a pain as the data needs to be persistent across a page reload (and hence you do end up using a cookie to track a temporary object that is then restored after login).
Have a read here:
And then I posted a video explaining more about how this works in the immediate follow up to the post reply:
Video: How to attach anonymous data to existing user after they log in? - #3 by keith
But I don’t see a need for your system to do anything like this. Creating new tasks should be reserved for authenticated users.