Hello!
I have an RG that contains our tickets. The workflow was designed to create a thing instead of modifying and overwriting tickets. My purpose is to track the changes each time the status if changed.
However, i need it to identify the ticket number and only show the last item specific to the item number.
How do I best do this that is optimized, and that it actually works?
:group by:ticket number
Actually could you also just not have an ‘isLatest’ field on the data type? When you create a thing, set isLatest to yes, and make changes to the previous ticket number thing saying isLatest = no. Then just search for things where isLatest = yes.
Group by must surely return more data from the Bubble DB than the isLatest method because group by returns: minimal data for each ticket (ref) + some data for the displayed ticket which is more than just displaying the ticket as the result of the isLatest search.
This would result in less things being returned from DB so less WU (I’d assume, but who knows).
Could it identify that I am making changes to the last ticket through the ticket number?
U need two datatypes, one is your actual Ticket with a field for its “last status”. And another is a History item with the status and a reference back to the Ticket
When they update the status it creates a new History item but also updates the actual Ticket’s Status
Yes. Each ticket isn’t identified by it’s number, they have a unique ID.
To simplify,
Ticket 1 - 1351809x1237095
Ticket 2 - 1239807x23105
Ticket 2 - 1930850x350187
Ticket 3 - 19085x1305879
When we say ‘make changes to current cell’s ticket’ if we’re looking at the second Ticket 2, we’re not making changes to Ticket 2, we’re making changes specifically to 1930850x350187.
But @tylerboodman is right in that you shouldn’t be creating a new ticket every time you change the status ideally - it’ll make your DB less cluttered and make it moderately easier to do stuff like calculate how many changes a specific ticket has had…
I see. So it is best to create 2 data base, where I use 1) create and 2) make changes separately. 1 actually holds the last status, while the other is “create things” to keep track of historical changes. Is this correct?
Yep, one datatypes is Ticket with a field for the Status (same option set as the History item)
Another datatype is “Ticket History” or something, that has a Ticket field (type Ticket) as well as Status (same option set)
Then your repeating group you can just search for Tickets, sort/filter by status, nice and clean. But if you need to pull up history on the Ticket you can search in a separate repeating group for “Ticket History” and constrain the search to the Ticket you want.
You can even make a Database Trigger for when the status changes on a Ticket. Have it make changes to the Ticket’s status, then create a new Ticket History. Then you don’t need to maintain the history relationship in your workflows, it will just automatically happen whenever Status changes.
It probably wouldn’t hurt to add a “Ticket History” list field to ticket, and add the newly created history to the list.
Thanks man! I was actually thinking of ways to do this in 1 DB, or data type, but I think this should be a simple solution to the issue, to actually store them in 2 data types - 1 meant for creating things (history), and 1 for making changes (latest status).
This topic was automatically closed after 70 days. New replies are no longer allowed.
