This prevents typos and using the constants makes it easier to find out what other items types are accepted.
It also makes it easier to see that these values are item types and not labels or descriptions.
Signed-off-by: Wouter Born <github@maindrain.net>
The code was already prepared for a nullable default service and then returns a 404 not found.
Fixes#2491
Signed-off-by: Wouter Born <github@maindrain.net>
The "summary" mode for `/rest/things` introduced in https://github.com/openhab/openhab-core/pull/1827
leads to these warnings in the console:
```
Field 'firmwareStatus' could not be eliminated: Can not set final org.openhab.core.thing.firmware.dto.FirmwareStatusDTO field org.openhab.core.io.rest.core.thing.EnrichedThingDTO.firmwareStatus to null value
```
The easiest solution to remove those warnings is to add it again to the list of fields included in the summaries.
Signed-off-by: Yannick Schaus <github@schaus.net>
I can't think of a good reason why listing things or querying their status should be allowed for users.
The things layer should only be of concern to admins IMHO.
As noted here: https://community.openhab.org/t/oh3-will-list-all-your-things-even-if-you-are-not-logged-in/108006/3
passwords and other sensible information in configuration could end up being exposed without auth required.
Signed-off-by: Yannick Schaus <github@schaus.net>
The /things, /rules, /ui/components endpoints retrieve all objects
in their entirety, which can become very big, i.e. channels, config
parameters, script rule modules or trees of UI components can
quickly add up to the size.
When the UI simply displays a list of those objects it retrieves all
this extra information but does nothing with it.
This introduces an optional ?summary=true query parameter for the
above resources to limit the output to pre-defined fields which are
deemed most relevant for displaying these lists, omitting the rest.
When the option is not set, the behavior remains unchanged so this
change is not API breaking. The API version has therefore not been
incremented. The client is responsible for adding the option to
retrieve summarized collections instead of the entire objects.
Signed-off-by: Yannick Schaus <github@schaus.net>
(I included these fixes in #1735 but extracted them in a stanalone
PR because it's easier to review and a little more urgent.)
As a result of the refactoring in #1713, the operations annotated with
`@RolesAllowed` containing `Role.USER` are not anymore automatically
considered accessible to all users, regardless of their actual roles.
4 operations are therefore now denied to admins if they only have the
`Role.ADMIN` role, as the first admininistrator is created only with
that role the UI encounters unexpected access denied errors and breaks.
(See https://github.com/openhab/openhab-webui/issues/422).
Closes https://github.com/openhab/openhab-webui/issues/422.
Signed-off-by: Yannick Schaus <github@schaus.net>
Also added "org.eclipse.jdt.annotation" to the test BOM so we can use "org.eclipse.jdt.annotation.Checks" in itests.
That class has many useful methods that help with writing more readable test code when using the Eclipse JDT null analysis annotations.
After running the resolver on the itests a lot of bundles were removed from the itest.bndrun files.
Signed-off-by: Wouter Born <github@maindrain.net>
