Would be nice to see more query parameter filters on the /users endpoint

Hey all, first of all would like to start this topic off praising the contributors of this project.

So wanted to start of with the main reason for starting this thread, so essentially i am trying to link my backend service with traccar and i am using the rest API, currently it is possible to load a list of all users and page them, but with no way to filter by email, id, surname, firstname and possibly by disabled, readonly statues too, i know i can achieve this by caching but i am worried about scaling this, it would be much more efficient to filter over the API and then cache the individual entries as i query for them on a per user basis.

Of course these should be administrator actions only, i just reckon this will be a very nice touch for the /user endpoint

Let me know your thoughts, is traccar open to feature requests like this?

King regards during these dangerous times and COVID 19. hope you are all keeping safe.

Kieran

I'm not against it, but then we should probably add this capability to other endpoints and make a common implementation. Feel free to send a pull request if you are interested in working on it.

Hey i will have a think on it, and agreed - filtering would be a very nice addition and you are right in saying there is no point in doing it unless its complete across multiple endpoints, i'm mostly interested in filtering users for an admin perspective to increase the usability from third party api integrations.

Thank you for your time, and hope all is well

Anton, i have made some progress on this, and have manged to filter users by a set of ids for admins which works nicely with the current object caching, however i'm getting 403 when trying to push a new branch, my username is kgrosvenor if i need to be added to access control

This is the error i am getting:

remote: Permission to traccar/traccar.git denied to kgrosvenor.
fatal: unable to access 'https://github.com/traccar/traccar.git/': The requested URL returned error: 403

Are you trying to push directly to the official repo? Obviously you won't be allowed. You have to follow standard GitHub PR flow.

Yeah i'm trying to push to the repo with my own branch name, then create a PR based of the branch? My bad i've been using GitLab for the past few years, but surely the flow is pretty much the same?

Yes, it is the same. You can't push directly to the official repo. You have to clone it.

I meant fork it.

Ohh i see, i'll take a look at doing that instead thank you!

Hey man, I've came up with another branch since we can already filter devices in a similar way to what i suggested by ID, and what i'm most interested in is mostly loading a user by ID so on other back ends i can quickly load the user model.

https://github.com/kgrosvenor/traccar/commit/9895d9bc3eb4f24edfc1b9171bbbead3a745845e

I did notice one bug though with devices, when you enter localhost:8082/api/devices?id=1&id=2 and 2 does not exist you get a null item in the response so this commit here fixes that and strips out null items:

https://github.com/kgrosvenor/traccar/commit/47087317fb4df8dc6fcb386df2d453d564e7a636

Feel free to send a pull request and we can discuss it there.

Hey anton, have another update to give. I had another bash at it last night and came up with a SQL string query builder method in DataManager, i came up with a POC users/filter endpoint which can take the query parameters and translate them into columns to query the database with different operations. The API is similar to what you may have seen before.

users/filter?eq_disabled=true

It is generic enough to work on positions too, for example we could do something like this:

positions/filter?gt_speed=20<e_speed=90

I need some time to fully implement this to wrap my head around it, and to ensure columns are properly validated, i have a working example. but just needs a bit more fleshing out with validation.

Another thing is how permissions should work, i could iterate the results and do some checks with the PermissionsManager and filter out results that way, does this sound more along the lines of what you were thinking?

You should not query database because we have all data in the in-memory cache.