Custom Fields, Not encrypted/decrypted when toggled in Custom-Field Settings Screen

[wirerydr]

Steps to reproduce

1. Create a custom-field category, and then a custom field. (The new field should initally default to "encrypt in database").
2. Create a new item, and make sure the custom field has a value.
3. In settings, edit the custom field to make it "not encrypted in database".
4. Go back and view the item. The custom field is blank. (Either empty, or not displayed).
5. In settings, edit the field again to make it "encrypted in database" again.
6. Go back and view the item. The custom field is still blank. The original value cannot be recovered.
7. In settings, create another new type of custom field, and this time change it right away to "not encrypted in database".
8. Create a new item, and set a value for the custom field.
9. In settings, edit the field to make it "encrypted in database".
   10 Go back and view the item. The custom field now looks like a very-long hexadecimal string.

Expected behaviour

All instances of a custom-field in the database should be stored encrypted, or in the clear, every time the setting of that field is changed from "encrypted in the database" to "not encrypted in the database" or back. At a minimum, the original value of the field should not become unrecoverable.

Note: It is understood that doing a dynamic decryption / re-encryption of potentially many instances of a custom-field whenever its parameter is toggled could be very slow. Perhaps instead of making it dynamic, it could be made into a task, just like encrypt or decrypt all file attachments is a task. However in this case there should probably be a reminder to the administrator that this task needs to be done otherwise the integrity of the custom-field is potentially compromised.

Actual behaviour

Either the field is blanked out, or converted to a very long hexadecimal string.

Server configuration

Operating system: Fedora 26

Web server: Apache 2.4

Database: MariaDB 10.1.25

PHP version: 7.1

Teampass version: Development commit 716c1b8

[nilsteampassnet]

Thank you for reporting this.

The bug here is related the fact that the code was not taking into account a field added in recently.
I have "robustified" this part by adding usage of this field making the items change on-the-fly possible.

The proposal given consisting in performing the change on "item opening" is good but it implies here too much changes in the code.
Nevertheless this is an excellent idea that I have added in the "structural changes" that version 3 of Teampass must take into consideration.

Thank you for good proposals.