New item with empty password not editable

[whosht]

Steps to reproduce

1. Login
2. Go to personal folder
3. Select "New item"
4. Fill in Label
5. Click "Save" -> Item is saved
6. Click Item
7. Click on "Edit"
8. Change any field (including password field)
9. Click "Save" -> Message "You are not allowed to do that!" + Log entry "TEAMPASS | user XXXXXXXX has no sharekey for item YYYY, referer: https://pw.who-ing.local/index.php?page=items"

Expected behaviour

Item should be saved.

Actual behaviour

Item is not saved, instead an error message is displayed and logged

Server configuration

Operating system: Debian 12

Web server: N/A

Database: N/A

PHP version: N/A

Teampass version: 3.1.1 (380c0f6)

Teampass configuration file: N/A

Client configuration

Browser: N/A

Operating system: N/A

Logs

Web server error log

[Wed Mar 20 09:45:14.936985 2024] [php:notice] [pid 207108] [client *.*.*.*:*] TEAMPASS | user ******** has no sharekey for item ****, referer: https://pw.who-ing.local/index.php?page=items

Log from the web-browser developer console (CTRL + SHIFT + i)

Edit 2024-04-02: Forget to mention Teampass version

[whosht]

Additional Information

• luckily the item can be deleted
• an entry in the sharekeytable of the database is not there
• an entry in the sharekeytable is not created if password is empty
• When saving an entry sharekeytable is checked if there is at least one entry for the item to be saved with the user that is trying to change the item.

With my limited knowledge of the source code I see 2 possible ways of fixing it:

• upon creation of an item a sharekey must always be written
• after editing and trying to save an entry with a previously empty password, the check for a sharekey shouldn't be taken into account
  • care must be taken, in case the edition is setting a password

One additional remark:

• I often use items with empty passwords for sites where it isn't necessary to document user/password (due to AD/LDAP-Users being used) but to document the 2FA recovery codes in the description field.

[whosht]

This might be related to #4061