Go to view after deleting an Item

Hy everyone,

When I select an item from a deck view and go into a detail view of that item, the Delete action is present on the Top Right, which is a great place.
But when I hit the Delete action, after that item is gone along with its View of it, it necessarily takes me to another view. And it chooses to take me to another detail view of the previous item in the list.
Is there a way to make it take me to the previous view, which was a deck view from which I selected the soon to be deleted item? Itโ€™s a pain to always have to hit the - go back button after deleting an Item.

Thank you

3 9 578
  • UX
9 REPLIES 9

Steve
Platinum 4
Platinum 4

Iโ€™m not aware of a way to accomplish that.

It is possible that we set the grouped action, delete to be followed by deeplink action to returns to the target view (deck view on your use case).
But once the delete action is fired within grouped action, then it is the end of the story. Whatver the subsequent action is set, for instance, to move back to the target view or others, the rest of the action never going to be fired.
Delete action is kinds of full stop. Once the delete row action is fired, nothing is going to happen, but the app behavior is to stay by default ie. we are not able to manipulate.
Delete row action means, at least for me, is to delete this row, as well as delete the rest of action states.

@Steve

  1. Delete single action
  2. Delete action followed by other action whatsoever (grouped action)

Those two actions are naturally works in exactly same way.

This is actually one of the area where Appsheet actions need to be improved.
On this use case, the deeplink expression to natigate to other view is not depending on the first action. Not row level action.
But once the row is deleted first, then Appsheet forgets everything, even though the subsequent action are not row dependency actions.
I remember I did discussed before with AppSheet dev teams, but so far the behaviors are the same.

For me, this story is illogical.

Grouped action, which are not row dependent should be fired even after the row is deleted.

@Steve

Iโ€™m not familiar with delete actions ending the sequence of grouped actions, so please excuse me if this question seems silly. But would the order of the grouped actions matter? What if after the grouped action is called it sends users back to the previous view and then deletes the record? Or would you have to find a way to store/identify the ID of the record you want to delete, return the users to the previous view, and then delete the record based on the identified ID?

It could be the almost same story.
If we swap the action order, deeplink to come first, followed by the delete action, yes, the user will be promptted by the other by the first action. But once it is fired, the second delete action will not be fired. This could be because that the view is moved from row level to other type of view (such as table or deck) then AppSheet no longer remember what the source row was. So not able to execute the delete action.
Same story at the end.

I, too, need this functionality. The deck view I use is based on a data slice that limits the deck items to rows that belong to the current user. When the user deletes an item, the previous item from the table -- not from the slice -- is shown, which means that the user can see other users' items. Is there a way to block the user from accessing someone else's record after they delete an item?

Whoa! I'd call that a bug! Please engage Support for help with this.

https://www.appsheet.com/Support/Contact

I too need this functionality. I think actions, triggers and bots scheme is suboptimal. If an action could be a trigger and task too, a lot would get simplified. 

Hi everybody....
As this thread was answered time ago, i wonder if it is any solution to this situation. I have an action, wich deletes rows from 2 tables, and when its done, it comes back to a detail view... i wonder if there is anyway to make it go back to a particular view, or how can i achive that. Or if you can give me any advice to avoid that, "structurally" speaking...

Thanks!

Thanks!

Top Labels in this Space