Feature Request: Send more fields to printer webhook to allow for customized labels

[TinkerTob]

Hi,

Would it be possible to send more data to the webhook when printing a stock entry label?

My preferred solution would be to send as much information as possible and let the webhook decide what to do with it. Maybe all the information visible on the "purchase" page, as well as product settings like parent, due date type, ...?

However, if that's not possible, the fields I'm most interested in are:

• Category
• Due date type
• The quantity unit the label refers to
• The date the stock entry was purchased
• The date the stock entry was opened

Thank you!

Best regards,
Tobias

Edit: Added "as well as product settings like parent, due date type, ...?" and "- The date the stock entry was purchased / opened"

[berrnd]

Technically already possible by utilizing Grocy's API:

• The webhook always includes the stock entry Grocycode, e.g. grcy:p:18:x64e2121a18196
  • Delimited by :, the third part 18 is the product_id, the last part x64e2121a18196 is the stock_id
• Get the complete product object by utilizing the endpoint /objects/{entity}/{objectId}, so e.g. https://demo.grocy.info/api/objects/products/18
• Get the transaction (stock journal) by utilizing the endpoint /objects/{entity}, so e.g. https://demo.grocy.info/api/objects/stock_log?query[]=stock_id=x64e2121a18196

[TinkerTob]

That's good to know, thank you! I guess I'll go digging into the API then.

However, I still think this would be nice to have for the following reasons:

• Complexity. From my POV, using the API would greatly increase the complexity of the webhook handler, while adding some fields seems like a rather small change to me. This is all the more relevant since API usage has to be implemented by each user on his/her own, while additional fields would be immediately available to everyone.
• Overhead. Using the API would require additional requests and processing (which on my RasPi 1B print server might actually be problematic). Just passing a few more fields shouldn't cause any issues in that regard.

Edit: Maybe it would be possible to pass both the product object and the transaction object inside the request? I guess that would automatically include all current and future fields, while dispensing with any complications that might arise from using the API.