Bug - customer_user_id null after ticket creation using an unknown customer user

[samueldc]

Environment

• OS: Windows 10 | WSL2 | Docker | Debian 11
• Browser: Chrome
• Znuny version: 6.3.4

Expected behaviour

After creating a new ticket with an unknown customer user (example: using an unregistered e-mail address) database must store the selected customer_user_id.

Actual behaviour

After ticket creation, the customer_user_id field from ticket table is null. The value is only updated after choosing People > Customer and updating the same value again.

How to reproduce

Steps to reproduce the behavior:

1. Create a new ticket for an user that doesn't have an account.
2. Query the ticket table and check null value in customer_user_id field.
3. Update the ticket using People > Customer and filling the customer user with the same value.
4. Query the ticket table again and check this time the value is stored in the database.

Additional information

Not sure if it's a bug. But two actions are at least inconsistent.

Screenshots

None.

[hanneshal]

Hi @samueldc I think that this is not a bug. The customer_user_id is null because there is no CustomerUser (the actual Business Object). The customer_user_id is the identifier of a customer user in the datasource for customer user.

Even if I change the customer again, to an unknown customer, it stays "null". Which is correct and the current behaviour. If you update the value to a registered Customer User, which is available in one of the backends, the value is updated. Which is also correct.

Maybe I miss something and you can explain why you would expect the ticket to have a customer_user_id without a Customer User.

Regards Johannes

[samueldc]

Hi @hanneshal, Thanks for replying. First, I think customer_user_id should always be saved, even if it's not in the customer user database (for example: a new user requesting to be registered in the database 😄). Second, it's ok you guys not agree with that. But, AgentTicketCustomer (ticket update) is saving that data already. The problem is AgentTicketPhone (ticket create) is not saving, so these two actions are behaving different. If it's allowed to save the information using a ticket update, why not allow the same using ticket creation?