Hi.
I’m creating a very simple ‘todo’ app for learning the different capabilities of bubble.is. The app allows multiple users, therefore I’m depending on the ‘created by’ field to match the todo tasks to each unique user.
The scenario I need help with;
On the landing page for the app, there exists in input for creating a task.
User can fill in the input and click ‘create’, before being logged in
The ‘create’ button determines the user is ‘not logged in’ and displays the log-in popup
Once the user log’s in → (this is where help is needed)
→ the information from the landing page task creation form should be used to create a new task for this user.
Here is what I tried after having trouble figuring out how to still have access to the values in the form
when ‘create’ is clicked, create a new task. This results in the task being created with the ‘created by’ field being blank. So I tried storing the user’s unique id in a field so I can find this task once the user is logged in.
show the log-in popup window so the user can log in.
Once logged in, find the task created, above. Once found, create a copy of the task so that the ‘created by’ field is populated for this user, by the system.
Once the original task is duplicated, delete it.
**The problem with this is that I’ve discovered the user’s unique id changes after the user logs in so it’s not a good field to use for searching.
Ultimately, my goal is to be able to ‘create a new thing’ for a user from the landing page and then match it to the user once they log in. If the user ‘abandon’s’ the site with-out logging in the the created things are discarded.
A similar use case is a shopping website where you can create a ‘cart’ and add items as you shop around. Once you log in, the cart is associated with your user profile. If you don’t log in, it’s simply discarded.
Usually for such scenarios, a session id and cookies are used to accomplish this task. How can this be done in bubble.is?
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:
Hi Keith,
Thank you for the feedback. I took your advice on ‘not’ letting a non-signed in user create a thing in my database. To not lose the ‘act now’ effect that I was after, I resolved this by letting it appear the user was creating a thing but they can’t ‘save’ until they log in/sign up. The log-in action returns the user to the original screen where their submitted information is still viewable and they can then hit ‘save/submit’.
