Userfield tracking

[Galapagon]

Unless all relevant information is provided, I can't help you

Describe the bug Unable to read userfield data from sensor.grocy_chores, only returns userfields: null.

Expected behavior Return something similar to "userfields": {"Room": "Garage"} as the Grocy API call does.

To Reproduce In the Grocy Add-On, Select "Userfields" inside "Manage Master Data" menu. Entity: Chores Name: Room Caption: Room Sort Number: 1 Type: Select List Confirguartion: (rooms including) Office, Garage, exc.

In Chores Overview, assign Room to chore. Chore will have userfield in API, but does not show in the integration.

General information to help debugging:

Chores and overdue chores are enabled and working

What is your installed versions of Home Assistant, Grocy and this integration? HA Core 2022.5.4 Grocy 0.17.0 (3.2.0) Grocy Component 4.3.1B

How do you have Grocy installed? Add-on or external? Grocy Add-On

Have you added debugging to the log, and what does the log say? yes, but nothing relevant is reported.

[marcelvriend]

Userfields have their own /objects/{entity} endpoint. The endpoints used by pygrocy for getting all tasks, chores etc. don't have it. Without losing other information, we have to do additional requests (preferably not per object). Which needs a change upstream.

[Galapagon]

Should I report this as an issue directly on SebRut/pygrocy? I'm not sure what I'd include, other than my original testing and Marcelvriend's comment. Thank you

[Galapagon]

Actually, it looks like it may have already been fixed upstream here, but for some reason was never implimented? https://github.com/SebRut/pygrocy/issues/200

[marcelvriend]

It is possible to do an additional generic GET request for chores to retrieve the user fields. However, due to how the Grocy API is designed, this implies one more request per chore. There are two Grocy API endpoints returning chore details:

1. /objects/{entity}/{objectId}
2. /chores/{choreId}

Most information is in both, but some only in one. So by simply replacing /chores/{choreId} with /objects/{entity}/{objectId}, information will be lost. The need to do a request per chore is already doubtful, so certainly not two.

If both endpoints should return the same information (except for the user fields), it is something to be fixed in Grocy first. If not, we should look into some sort of caching before doing more requests per chore. Although we should probably do that anyway.

[Galapagon]

I'm understanding a bit better now, I see the differences between api/objects/chores and api/chores now

[Galapagon]

Turns out this is a "bug" all the way up at the Grocy level itself. https://github.com/grocy/grocy/issues/1484