Mismatch between the Events and the Transfers lists

[felivix]

A record in the Events list disappeared from the Transfers list:

Events:

Transfers:

The record appears here after the manual correction by Luzius:

I think there is a problem (bug) in the Transfer function. In the example below I could transfer traditional shares from the corresponding Felix Kaegi record to the token record of Felix Kaegi. BTW, I used this function to merge the traditional shares record of Klaus Galler with his token record. Later by modifying the name of his traditional shares record (which by then didn't contain any traditional shares) I crashed your database. Do you want to disable the transfer function between the traditional shares record and the token record of the same user?

[muratogat]

Thanks for the report. @KostasZav I think we should disable selecting the same the sender and recipient in this dialog. This is not the intended function and can result in unexpected behavior.

[KostasZav]

Sure, thanks for your feedback @muratogat. Is it Mateusz or Jan who can fix it?

[KostasZav]

@pansay @mateuszstaszkow Can someone please have a look and fix this (see Murat's comment above)? Thanks

[luziusmeisser]

There are several points to explain here:

1. The events are low-level and show you when the token was transfered. The transfers in the transfers table are at a higher level and require two things for a successful transfer: the token transfer itself and the shareholder registration. The Timestamp of the transfer is whatever is later. If you bought the shares yesterday and register today, you will only appear in the shareholder registry starting today. Registration ist not retro-active.
2. There is only one Felix Kaegi in our database. There isn't a shareholder record and a token record. It is the same person.
3. Transferring shares to oneself is like transferring 0 shares. It is a transaction without effect. However, I would not prevent the user from selecting the same sender and recipient.

Use case for selecting same sender and recipient is the following: assume you want to send shares from Murat to Felix. You accidentally select Felix as the sender, but then realize it is actually the receiver. So you click on the receiver drop down to select Felix there, planning to set Murat as the sender afterwards. I think it would be very confusing for the user if Felix would not appear on the list of possible recipients and we would probably get an error report like "Felix does not appear in the recipient dropdown menu". Therefore, I would say we keep everything as it is.

[luziusmeisser]

PS: What we could do of course is disable the "add record" button and show some feedback if the number of selected shares is 0 or both the sender and recipient are the same. However, in that case, you need to be careful with the implementaiton as the button should be enabled for transaction types where one of the two fields is hidden even if they are the same. E.g. if the user selects the same person for both sender and receiver and then changes the transfer type to "issuance", thereby making the sender field hidden, the button should be enabled again.

[KostasZav]

PS: What we could do of course is disable the "add record" button and show some feedback if the number of selected shares is 0 or both the sender and recipient are the same. However, in that case, you need to be careful with the implementaiton as the button should be enabled for transaction types where one of the two fields is hidden even if they are the same. E.g. if the user selects the same person for both sender and receiver and then changes the transfer type to "issuance", thereby making the sender field hidden, the button should be enabled again.

Is this something we already have on our backlog or do we need an additional issue in the dashboard repo? Afaiu, this isn't a high prio task and can be implemented at a later point in time.

That said, I'd suggest to close this issue (for backlog management purposes) given that our intention of not disabling the transfer function when sender and recipient is the same person is clear and agreed by everyone.