feat: allow editing item name in cart for single invoice

[aperebaskine]

Description

This PR allows users to modify an item's name in the cart, for the corresponding invoice only. This is useful as some small businesses do not register an entry for every single of their SKUs on sale, opting instead use a more general item entry and specify a name on a per-invoice basis.

This does not update the item's original name nor does it allow the user to tamper with the item code (the actual identifier for the SKU in the database).

This is an updated version of PR #27, which may be closed following the merging of this one.

Implementation details

As requested in PR #27, a check field in POS Settings has been added to toggle this feature.
If the feature is enabled, within the item edit dialog, the item name is replaced with an input field. A function is added to restore the original name from cache, which can be triggered manually via a button in the UI, or automatically on blur if the field is empty.

To improve UX with this feature enabled, item code is now also displayed below the editable item name.

[aperebaskine]

Added a new commit: item code is now displayed below the item name in the edit dialog

[aperebaskine]

Potential improvement: validate server-side that item name in the form data matches the item name in the database when "Allow Custom Item Name in Cart" is disabled. I'm not seeing any currently implemented logic that already validates item names in form so I'm not sure if this is necessary.

[engahmed1190]

Thanks I will start reviewing this code.

[git-avc]

Potential improvement: validate server-side that item name in the form data matches the item name in the database when "Allow Custom Item Name in Cart" is disabled. I'm not seeing any currently implemented logic that already validates item names in form so I'm not sure if this is necessary.

IMO this make no sense, because in case od disable this new option item_name on form will always match the item_name in Item doctype since it is fetched from there.

Maybe I am missing something

[aperebaskine]

@git-avc even when the option is disabled, item_name is sent by client so in theory it would be possible to construct and send manual API calls (bypassing the front-end) with modified item names. The question is whether it's necessary to prevent that or not.

I'm assuming this was deemed unnecessary since there's no validation to begin with but thought it was worth mentioning.

[engahmed1190]

My Concern about this PR what will prevent the Casher to sell a higher rate item with Lower rate by just changing the names. e.g. IPhone 13 can be Sold as IPhone 17 by just renaming.

[git-avc]

Hy @engahmed1190 @aperebaskine

Purpose of this is let people use POS system without all the items created ... Imagine a printing services shop. We have some items/services created (A4 color print, A4 BW print, ...) but need to specify on the item name something related to the job (ADS PROTOTYPE, CAMPAIGN SAMPLE ...). Maybe we can configure 1 item group for that ... We can consider too add a custom field to Item Doctype (something like "Let change item name on POS")

[aperebaskine]

@engahmed1190

Your concern is valid, here are possible steps we could take to solve this problem:

• As per @git-avc's suggestion, we could add the ability to enable this for specific item group(s). This seems like a good approach to me, as it adds more fine-grained control on what kind of items can have their name modified.
• I would also suggest adding the ability to control this on a per-role or per-user basis, so that the feature is only enabled for trusted users.
• It might also be helpful to allow toggling whether to show item code alongside item name in the default receipt.

This would have to be implemented in Desk, removing the toggle inside the settings menu of the front-end.
I'd like to know your thoughts before I work on this. Thanks!

[engahmed1190]

@engahmed1190

Your concern is valid, here are possible steps we could take to solve this problem:

• As per @git-avc's suggestion, we could add the ability to enable this for specific item group(s). This seems like a good approach to me, as it adds more fine-grained control on what kind of items can have their name modified.
• I would also suggest adding the ability to control this on a per-role or per-user basis, so that the feature is only enabled for trusted users.
• It might also be helpful to allow toggling whether to show item code alongside item name in the default receipt.

This would have to be implemented in Desk, removing the toggle inside the settings menu of the front-end. I'd like to know your thoughts before I work on this. Thanks!

This seems good plan

[engahmed1190]

Once it ready let me know

[aperebaskine]

@engahmed1190 I've finished making the changes.

Now, to use item name customization, it must be enabled in Desk in both POS Settings and Item DocType. For POS Settings, I've added a Table MultiSelect to select the users that can use the feature, but I noticed that POS Profile already maintains a list of users for said POS so this may be redundant. Let me know what you think.

In the UI, the name will only be editable if the feature is enabled in both POS Settings and Item DocType and if the currently logged in user is in the list of allowed user in POS Settings. I've also added server-side validation for the item names in update_invoice endpoint.

For now, I've made it so item code is always displayed in the edit dialog. Let me know if you want changes on that.

[engahmed1190]

Thanks @aperebaskine for the update — I’ve tested the implementation and it’s working as expected 👍

I have a few enhancement suggestions that would improve scalability, clarity, and UX. Please consider the following points:

---

1. Role-Based Control Instead of User-Based

Rather than enabling item name editing at the individual user level, it would be more scalable and maintainable to control this via user roles.
This approach:

• Aligns better with permission management
• Reduces configuration overhead
• Scales more effectively across large teams

---

2. UI Structure Improvement

The current standalone section for Item Name Customization could be merged into a more relevant or existing section.
This would improve:

• UI consistency
• Logical grouping of related settings
• Overall user experience

---

3. Minor: Function Return Type Clarity

The function is_item_name_customization_enabled_for_user currently documents a return type of 0 | 1.
Since Python does not enforce this strictly, it would be clearer to explicitly use:

• -> bool or
• -> int
  to improve readability and type expectations.

---

4. Potential Edge Case: Whitespace-Only Item Names

The handleItemNameBlur() logic correctly restores the original name when the input is empty.
However, item names containing only whitespace may still pass validation.

Suggestion:

• Trim the input before checking emptiness to avoid unintended blank names.

---

5. UX Enhancement: Controlled Edit Mode

To prevent accidental edits:

• Add a pin (or edit) icon in the Item Detail view
• Keep the item name read-only by default
• Enable editing only after explicit user action

This provides better control and a clearer user interaction flow.

---

[engahmed1190]

Please rebase and fix the conflicts. Thanks ..