Splync 1.14 Memperkenalkan Hard Delete dan Soft Delete untuk Perbelanjaan

Hard delete menghapuskan data dari pangkalan data secara kekal melalui pemadaman fizikal. Sekali rekod dipadam dengan cara ini, ia tidak boleh dipulihkan kecuali jika terdapat sandaran. Soft delete berfungsi secara berbeza. Daripada memadamkan data secara fizikal, sistem menandakan secara logik bahawa ia telah dipadam. Data kekal dalam pangkalan data tetapi dianggap tidak aktif. Oleh kerana itu, rekod yang dipadam secara lembut biasanya boleh dipulihkan kemudian. Setiap pendekatan mempunyai kelebihan dan kekurangan dari segi integriti data, pematuhan, dan pengalaman pengguna. Merancang perkhidmatan perkongsian perbelanjaan yang boleh dipercayai dan mesra pengguna bermakna mencari keseimbangan yang tepat antara pengekalan data dan pembersihan. Di Splync, keseimbangan itu penting untuk kepercayaan dan kebolehgunaan.

Sebelum versi 1.14, memadamkan perbelanjaan dalam Splync bermakna pemadaman segera dan kekal dari pangkalan data. Ini mencipta masalah yang halus tetapi serius, terutamanya kerana Splync direka untuk membantu pasangan dan rakan menguruskan bajet bersama dengan mudah. Bayangkan sebuah projek berkongsi dengan puluhan perbelanjaan. Jika rakan atau pasangan memadam entri, sama ada secara tidak sengaja atau sengaja, data tersebut hilang tanpa jejak. Ini boleh menyebabkan pengiraan penyelesaian yang salah dan, lebih penting, menghakis kepercayaan antara ahli. Dalam banyak kes, pengguna tidak sedar bahawa ada yang hilang. Versi 1.14 menangani ini dengan memperkenalkan keterlihatan dan kebolehpulihan. Sekarang, apabila perbelanjaan dipadam, pengguna dimaklumkan dan diberi pilihan untuk memulihkannya jika perlu.

Dalam versi 1.14, kebanyakan pemadaman dikendalikan sebagai soft delete. Apabila ahli projek memadam perbelanjaan, ahli lain menerima pemberitahuan. Pada masa yang sama, perbelanjaan tersebut dipindahkan ke keadaan "sampah" dan bukannya dipadam secara fizikal. Jika ia dalam tempoh 7 hari dari pemadaman, mana-mana ahli projek boleh memulihkan perbelanjaan ke senarai perbelanjaan aktif. Ini mencerminkan bagaimana banyak sistem moden mengendalikan pemadaman, mengutamakan keselamatan berbanding keakhiran. Walau bagaimanapun, tidak semua kes harus dilayan sama. Bagaimana jika pengguna tidak sengaja menambah perbelanjaan peribadi ke dalam projek kumpulan, atau entri itu tidak relevan sama sekali? Pemadaman serta-merta mungkin diperlukan untuk mengelakkan kekeliruan atau kebimbangan privasi. Dalam kes ini, memaklumkan semua orang dan mengekalkan rekod yang boleh dipulihkan mungkin tidak sesuai.

Untuk menangani kes-kes ini, Splync 1.14 memperkenalkan syarat terkawal untuk hard delete. Perbelanjaan boleh dipadamkan secara kekal tanpa pemberitahuan jika pengguna yang memadamnya adalah pencipta dan pengedit terakhir perbelanjaan tersebut, dan jika pemadaman berlaku dalam masa 30 minit selepas perbelanjaan itu dibuat. Apabila syarat-syarat ini dipenuhi, sistem menganggap tindakan itu sebagai pembatalan cepat dan bukannya acara yang dikongsi. Semua senario pemadaman lain secara lalai kepada soft delete. Dengan cara ini, Splync mencapai keseimbangan antara fleksibiliti, privasi, dan ketelusan.

Kami mereka bentuk ciri ini agar berasa seintuitif mungkin. Dalam versi 1.14, kami menambah butang penapis baharu di sebelah butang penapis ahli sedia ada, membolehkan pengguna menukar antara perbelanjaan aktif dan yang dalam sampah. Akibatnya, kawasan penapis dan pengisihan UI telah dikemas kini sedikit. Untuk memastikan antara muka tetap ringkas dan mudah difahami, butang penapis kini menggunakan simbol. Untuk perbelanjaan aktif, pengguna boleh leret ke kiri untuk memadamnya. Selepas mengetik butang padam, amaran muncul untuk menjelaskan sama ada tindakan itu akan menghasilkan hard delete atau soft delete, jadi pengguna boleh meneruskan dengan yakin. Untuk perbelanjaan dalam sampah, pengguna boleh leret ke kiri untuk memulihkannya.

Setelah kami meningkatkan aliran pemadaman perbelanjaan, langkah seterusnya adalah untuk menjadikan pemadaman projek lebih fleksibel. Pada masa ini, pengguna hanya boleh memadam projek selepas menyelesaikannya. Tiada cara langsung untuk memadam projek yang belum selesai, yang bermakna pengguna perlu melalui langkah yang tidak perlu sebelum menghapuskan projek. Ini boleh menyusahkan dalam kes di mana projek dicipta secara tidak sengaja, diduplikasi secara tidak sengaja, atau tidak lagi diperlukan. Meningkatkan pemadaman perbelanjaan adalah langkah penting ke arah menyelesaikan isu ini, kerana memadamkan projek adalah lebih kompleks daripada memadam perbelanjaan tunggal. Ia boleh menjejaskan perbelanjaan, baki, dan kepercayaan semua ahli projek yang terlibat. Atas sebab itu, pemadaman projek memerlukan reka bentuk yang lebih teliti. Penyelesaian yang lebih baik sedang dalam perjalanan.