Hi @Chaosflo ,
The device.getAll() method was dropped intentionally in v17.0.0 since we found that many users where fetching all devices and then were filtering on client side, instead of adding a $filter in the optional parameters and letting our backend do the filtering, thus saving CPU & bandwidth on edge devices.
The suggested approach is to use device.getAllByApplication or device.getAllByOrganization, which on later observations we also found that it is more performant for big fleets (because of how permissions are applied on our backend).
Moreover this using those methods upfront makes automations be implemented in a more precise & scoped way (rather than globally), which prepares them for a future that they might have multiple orgs or fleets.
On top of that, it also avoid scripts accidentally affecting incorrect devices, for example affecting devices of other fleets because the user was just added as an Operator on it.

We would love to hear more on what your use case is, and help you use a method that exactly matches your use case.
What are the current methods limiting you to do, that if we added then you would be happy using them?
For example, would supporting providing multiple organizations or applications in device.getAllByApplication / device.getAllByOrganization allow you to use those?

Kind regards,
Thodoris

Hej @thgreasi !
Okay that's a valid reason =?
So our use case is to show all devices from all fleets and applications, so we need all applications.
If I would filter by application or organization I would make more requests than just one.

I will explain a bit my use case so that you can make a picture in your head!

We want to show the user all devices in a table, show tags (which were applied to the devices) as columns to filter on.
For a device we then have a detail view which shows special fields which is interesting for us.
Pretty simple.

Yeah that should be it =)
I hope your understand that I cannot go further into detail because of company rules, u know ^^

Greetings
Florian

Let me give you a pine query that does exactly what you described which you can use right away (until we extend the device.getAllByOrganization to accept multiple organizations in its parameters):

await sdk.pine.get({
	resource: 'device',
	options: {
		$filter: {
			belongs_to__application: {
				$any: {
					$alias: 'bta',
					$expr: {
						bta: {
							organization: {
								$any: {
									$alias: 'o',
									$expr: {
										o: {
											handle: { $in: ['org1handle', 'org1handle']}
										},
									},
								},
							},
						},
					},
				},
			},
		},
	},
});

In my opinion, the org handles should be a parameter for your application, and that way allow you to scope the results.

To be clear, this is not just for performance reasons, but it also avoid future surprises:

• imagine if the user that your application is authenticated with, at some later point gets added to a test fleet with offline devices and those show up unintentionally on your application causing false alarms
• or if at a later point we grant all users permissions to access some common test devices on the platform.

Something similar has happened in the past with users that were retrieving all release_tags without any filter, so when we re-modeled our OS releases as plain public releases ("dogfooding" our platform) and added tags to them, those users had update their applications and filter their queries more precisely.

As a result it is always suggested to avoid unfiltered queries, since what you currently have access to might change, and in most cases does not precisely match what you want to present.