* Remove _REPOSITORY_ permissions -> replaced with _SOFTWARE_MODULE_, _SOFTWARE_MODULE_TYPE_, _DISTRIBUTION_SET_, _DISTRIBUTION_SET_TYPE_ permissions
* Still kept _ROLE_REPOSITORY_ADMIN_ role granting all repository fine-graned permissions
* Added dedicated _TARGET_TYPE_ permission set - the _TARGET_ permissions just grant _READ_TARGET_TYPE_ (analogically _SOFTWARE_MODULE_ permissions grant _READ_SOFTWARE_MODULE_TYPE_ and _DISTRIBUTION_SET_ grants _READ_DISTRIBUTON_SET_TYPE_
* Hierarcy is not configurable - could be completely replaced by setting spring application property org.eclipse.hawkbit.hierarchy or could be extended by adding rules using org.eclipse.hawkbit.hierarchy.ext
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
keeps backward compatibility by being able to fallback to JAVA_SERIALIZATION
+ fix DMF messages with status code
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
* Add common "interface" for metadata supporting entities
* Add common metadata implementation for distribution set and software module
* Extract PermissionSupport + extend by TargetManagement
* TargetManagement tags are now protected by Target permissions - as it should be
---------
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
* Move EventPublisher to hawkbit-repository-core making hawkbit-repository-api non dependent to rabbit binders
* Move EventPublisherHolder to org.eclipse.hawkbit.repository.event
* Fix overriding default values of RemoteEvents and rabbit binder
---------
Co-authored-by: vasilchev <vasil.ilchev@bosch.com>
1. Introduce @PrreAuthorize check based on hasPermission - allowing custom processing (compared with non-modifiable hasAuthority/Role processing)
2. Dedicated permissions could be implemented on management api level. Check is made by plugged in PermissionEvaluator
3. Thus common XXX_REPOSITORY permissions could differ for extending services
4. Change create/update entity builder pattern - not via EntityFactory but via clean static lombok based builders (with fine fluent api).
5. Implement abstract repository management jpa class that handles the boilerplate code from extending classes in single place consistently -> AbsreactJpaRepositoryManagement
6. Register management api-s as **Sevice**-s instead of **Bean**-s in order to make easier maintainable and get away from heavy argument forwading
7. Simplify custom hawkbit repository registration + adding proxy to handle exception mapping at lower level - thus not depending on Aspects for converting exceptions
8. Implemented general purpose 'copy' utility (ObjectCopyUtil) that using getter/setter patterns is able to copy (e.g. Create/Update) objects to other objects (e.g. JPA entity objects)
* Add support for pollingTime overrides
* the current format HH:mm:ss is still supported
* add option for deviation percent (HH:mm:ss~\d{1,2}%) which allows the system to do some randomizing of the poll interval
* add support for overriding default polling time interval for devices matching some RSQL filters (in order), e.g. 01:00:00~10%, group == 'eu' -> 00:02:00~15%, status != in_sync -> 00:05:00
* IMPORTANT: overdue time is calculated according to the default polling time. So, the overdue status might be incorrect for targets with overridden poll interval
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
* Remove min polling time from the tenant config - it is a system configuration
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
* Add support for bigger poll intervals and overdue + duration format config support
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
* Move Query Language (RSQL) in separate package - hawkbit-repository-ql
* Add Entity Matcher which match an entity object agains filter
* Spec to string utils now in runtime (as a library) - could be used in tests or to dump something in runtimes
* Move eclipselink/hibernate profiles in new QL module, this way provided / set to hawkbit-repository-jpa
* Remove unused javax.el imports
Since static assigments of dynamic rollouts always override the oldest rollouts
it seems more consistent if this is the case also with dynamic assigments. I.e.
all older are overriden and if there are actions of newer rollouts - won't be assigned.
Signed-off-by: Avgustin Marinov <Avgustin.Marinov@bosch.com>
