Allow Clearing of Swap History

[jansako]

Issue: It is currently not possible to clear out the swap history from within the UI.

If a swap filter is introduced for the list, the 'clear' history should respect the filter and only delete the displayed swaps.

[Milerius]

this should be possible @naezith, but i guess we will wait for the new UI to implement it

[naezith]

Another feature to consider at UI design @ca333 , if it's wanted, I'll need the backend @Milerius

[cipig]

Please be careful with deleting swap jsons, they are also needed to recover funds from failed swaps.

[jansako]

My issue is only concerned with UI & user interaction. Maybe the implementation could be that the cleanup moves the (failed) swap JSON's into an 'archive' folder so they would not display in the application, but still be available for manual troubleshooting?

Or possibly as a best practice, any 'failed swap' JSON should be copied to an "failed swaps" folder by default if these are the only way to recover stuck user funds. Then it does not matter if the user clears out the list.

[tonymorony]

Clearing swap history / failed swaps might be quite tricky and possible dangerous ( in case if we delete / archieve failed swap but it needs refund lets say as cipig mentioned)

In 0.3.0 we introducing swap history filtering:

if also add filter by swap status (failed/success) or tick to display only sucessful swaps and keep filter state on re-login it might solve the raised problem from UI / user interaction perspectives I think. Do you think it's fine @jansako ?

[jansako]

@tonymorony I see what you are trying to do, it could work.

• Consider having a default filter state. I would suggest showing all swaps for the last 30 days and hide the rest. The 'Export CSV' button should respect the selected date range/filters.
• I feel the 'Enable filters' button is unnecessary, the filters should be visible by default. Then the user can hide or display what they want.

From the performance standpoint, is there a limit on a number of swaps in the folder that would start to cause performance issues? In the future there could be many thousands of swap records in the database, especially if the users are able to combine the upcoming 'multi-order' feature with bots. If this is a concern, some sort of mechanics for clearing the swap history should still be considered.

[tonymorony]

The 'Export CSV' button should respect the selected date range/filters.

The export button works like that at the moment (exporting filtered swaps)

I feel the 'Enable filters' button is unnecessary, the filters should be visible by default.

Disabled "enable filters" (probably more precise naming is "apply filters") button just displaying unfiltered data (all swaps from local DB). Maybe it worth to implement it as "reset filters" but current toggle allows to keep filters presets if user want to check unfiltered data and then back to his filter preset.

From the performance standpoint, is there a limit on a number of swaps in the folder that would start to cause performance issues? In the future there could be many thousands of swap records in the database, especially if the users are able to combine the upcoming 'multi-order' feature with bots. If this is a concern, some sort of mechanics for clearing the swap history should still be considered.

I do have around ~500 swaps in local DB and do not have any performance decrease. Thank you for suggestion on last 30 days swaps displaying, we've had such idea also. My concern is that it might confuse some of the users who do not swap much/often: they might login in a few weeks/months, don't see the swaps and think that history is cleared. And from another side experienced users who has hunderds/thousands of swaps can set required filters manually (we just need to keep filters state on application restart). So yeah, as soon as it became a problem we might definetly think about some sort of old swaps "archivation" into backup folder (let say if user's history grow ower N swaps). Maybe upon this time there will be some kind of database with status information on adex api side.

[Milerius]

We now have pagination now - closing.