Can someone confirm if what I’m trying to do can or cant be done please?
In regards to deleting a thing, I have a pop up that is used as a confirmation deletion box (Are you sure you want to delete Parent groups title/name?). With Buttons Yes/ No.
All good so far the content is set to company history with the source being do a search for company history.
Now comes the issue.
I want to use the same pop up to delete other data type things…
so I send a URL parameter called (“del” = parent groups unique id). then in the popup conditionals I have when get del from url is do a search for "category"s:first items unique Id
Constraint: unique Id= get del from url
Change data source: do a search for "category"s: first item
Constraint: unique id= get del from url
HOWEVER! I cant do this as I get an error saying the content is set to “company history” and the data source is trying to be set to “Category”.
So what can I do to make this work?
I have to have a data source set in the popup so that it knows what thing to delete.
I have to have a content type set so I can have a data source.
I cant conditionally change the content type
If I remove all content type and data source set the delete button to do a search for “Company history” with constraint unique id= get del from url then I cant conditionally change this either to suit other data type as well as I can dynamically have an alert message show afterwards as there is no data source.
the popup should have a set of custom states for each type of data you would allow the user to delete. If Bubble ever gets around to fully realizing new feature releases, then we could use the properties feature for this but it is not possible to run a workflow action to set the value of the property. But if you are using the popup in a place where you can set the property value (think in an RG, the property could be set to ‘current cells’ thing’), you can use properties but custom states work best as we can run an action to set the state.
Set conditionals on the visual elements so your messaging is appropriate for each type of data to be deleted. These conditions would be something like ‘popup custom state for data A is not empty’…this is done for each custom state/data type the popup is used for.
Set the workflow action using the button that triggers the delete actions. Have multiple actions, one for each data type with the condition to only delete it when the ‘popup custom state for data A is not empty’…similar to conditions on the visual elements, you do this for each data type to be deleted.
When you are using the popup on the page, you will need to run the action to set state for the data type to be deleted. The custom state would be the actual ‘thing’ to be deleted.
When the popup is closed run the action to clear the custom state values.
I did the same by creating a Delete Icon as a Reusable Element with two mandatory Inputs. Include the Popup as the part of this RE itself and you should be able to manage custom messaging for all datatypes as well.
This is also an interesting solution and one I’m happy to also explore. Thanks for the info.
So you just set up OS’s to match all the data types you had then you could choose which one to apply to tue RE when dealing with that particular data type?
@progressdiary
OS values be anything. You just need to manage the respective mapping in your “Only When” conditions for a series of Delete Actions
For eg:
Datatype: User, Product, Order, Task, Project
OS: 1,2,3,4,5 or User, Product, Order, Task, Project (Preferred, its easier to manage when list grows)
Action 1: Delete User (Only when OS is 1 or user)
Action 1: Delete Product (Only when OS is 2 or Product)
…
…
So on.
The properties show the content. isDanger changes the button to red when true. confirmText/confirmIcon are the text and icon on the confirmation button.
The reuseable element has two states - isConfirmed and isCancelled.
When I want to allow something to be deleted, stick the popup on the page as below. Reset and show the popup when the delete icon (or whatever) is pressed. Additionally, on the page, store a state/variable for the item you’re trying to delete if necessary. I prefer groups to states but I’ll call it a state for simplicity. So, we’ll Set state of Element X to ‘the Thing we want to delete’.
When the popup’s confirmation button is pressed, we set the state of the popup isConfirmed = yes, and then hide the popup.
On the page, Do when condition is true isConfirmed = yes → Delete Element X’s Thing (or wherever you stored the Thing you’re confirming deletion of on the page).
For the user, that looks something like this:
In the editor, it looks like this:
TLDR; 1. Make a reuseable popup 2. Know when the deletion is confirmed using a state on the popup 3. Run the deletion actions outside of the popup in the relevant place (using a BE workflow if you want it to be modular and the same deletion logic to work in multiple places across the app)
Not loads of conditionals, can be used anywhere and not just for deletion, works great and fully reuseable and modular. Modularise your apps guys!
Swapping out the conditionals on the action for conditional triggers, I like it. Interesting approach and use of the properties on reusables.
With this approach if I have a dashboard from which the user can delete 3 or 4 different data types, do I need to have 3-4 instances of the reusable popup on that single dashboard page, or can I have just one instance of the reusable popup?
You could have 4 instances of the reuseable popup and listen to each one separately.
Alternatively, if you ensure that there’s only ever one saved ‘Thing you’re deleting’ (i.e when they try to delete something, you reset all of the other deletion states/groups), you can use a conditional like ‘when popup’s isConfirmed is yes and state X is not empty’.
I’d probably just go with the 4 popups though as it’s more straight forward. Performance difference negligible.
I use this confirm action popup for everything, not just deletion, it just makes it really handy to have something like that be reuseable as it reduces development time and ensures UI consistency.
These are all great responses, Thanks @georgecollier I like that this is modular and can be used anywhere and not just for deletion.
Forgive my ignorance with this next question, What are you referring to with a “BE Workflow”?
This is very new for me, So I may be asking very simple questions here (but please be patient and humor me haha)
I can set the properties on the RE Page popupConfirmationAction and I just followed exactly what you have (I left the field Optional as checked as that how it was but with no default value)
I also set the two states on this
isConfirmed - YES/NO default=No
isCancelled - YES/NO default=No
I click delete on the Thing I’m deleting and thisshows the popupConfirmationAction RE
Can you explain the workflow section a little more please? I set the isConfirmed state to be yes when button Delete is clicked. I see you are using an API workflow… Can I complete this action without an API workflow? Or is the API mandatory for this? (learning on the free account for the moment)
But I’m also not sure how to change this for deleting different data types on a single page.
e.g. I have a page called admin_create. This is a page that anyone with the admin user roll can create an entry for different data types (and edit also using that data types specific form, there are currently 9 different forms on the one page that create different entries
What I would like to do is use this one delete to be able to delete entries on each data type, Is that possible to achieve with the set up you have suggested?
NOTE: I’m also very well aware that I wont be able to complete this app on the existing free account I’m using. But I’m building this app to add to a portfolio of what I’ve created and also to learn how to build with bubble.
The reusable element itself should be of type popup. Currently you have a RE that is a group, with a popup inside.
Yes - the action is just what you want to do when the popup is confirmed. For me that means running a backend API workflow. For you that might be Delete a thing.
Yes! All this popup does is provide a way for the user to confirm something. You set up the workflow on the page that contains the RE that dictates what happens when this popup is confirmed.
I use a reusable popup + states + reusables for logic. Was looking to use backend workflows for logic, but to have backend workflows return the result of an action immidiately and run under current user you would have to (1) create the backend api workflow for the action (e.g. deletion) + backend api authentication workflow, (2) create the api’s in the api connector (for that immidiate return of the result) I would expect. Or does anyone know of another way (without over engineering and WU inefficiency)?
*For the above, when using option sets, the BE workflow should take a text parameter and find the option by filter, as option sets are not reliably supported.
Thanks G and thanks for that article, I tried that the second (maybe 5) after you posted it. But is uses an API key from tab API right instead of current user, but you use a login action (and maybe some logic to not have to use username and password)?
You can run backend workflows either as an admin using an admin API token, or a user using their login details by getting the token from a BE workflow. I’ve never done the second option as I just use admin access and haven’t had a need for the user access (though only authenticating as a user would arguably be preferable as it would obey privacy rules)
Yeah I use that second option in a couple of situations, but don’t like to sending user credentials, but we can prevent that using some add. logic.
Exactly, once made the mistake to do a search with option ignore empty constraints in a backend API and ended up sending clients too much data. I always try to prevent using those API-keys since that day.
Thanks @georgecollier and @gerbertdelangen. This is great knowledge to have, I must admit it’s over my head at the moment but I’m happy to have it explained here for when I can get to it and what I’m reading make sense to me. … Soon I’m sure.