Fix for the incorrect device statistics shown in the app store. #508
Merged
tcdlpds
merged 6 commits from ruwin/device-mgt-core:statistics
into master
2 months ago
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'ruwin/device-mgt-core:statistics'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Purpose
Description
This pull request addresses a bug fix to the incorrect device statistics shown in the app store.
The following changes have been made:
List<Integer> removedIds = devices.stream()
.filter(device -> {
String status = String.valueOf(device.getEnrolmentInfo().getStatus());
return "REMOVED".equalsIgnoreCase(status) || "DELETED".equalsIgnoreCase(status);
use the constants. there are constants for statuses, you can use them instead hardcode them here
List<Device> devices = HelperUtil.getGroupManagementProviderService().
getAllDevicesOfGroup(subscriptionInfo.getIdentifier(), false);
List<Integer> deviceIdsOwnByGroup = devices.stream().map(Device::getId).collect(Collectors.toList());
List<Integer> removedIds = devices.stream()
This filter process can be done by single step.
!"REMOVED".equalsIgnoreCase(status) || !"DELETED".equalsIgnoreCase(status)
use this in the filter, so u can get the required device ids after mapping them.getAllDevicesOfGroup(subscriptionInfo.getIdentifier(), false);
List<String> deviceStatuses = Arrays.asList(EnrolmentInfo.Status.ACTIVE.name(),
EnrolmentInfo.Status.INACTIVE.name(), EnrolmentInfo.Status.UNREACHABLE.name());
List<Device> devices = HelperUtil.getGroupManagementProviderService().getAllDevicesOfGroup(subscriptionInfo.getIdentifier(), deviceStatuses, false);
In this service method are we considering the device type of the application supported?
Yes, your point is valid, but in the latter part
SubscriptionStatisticDTO subscriptionStatisticDTO = subscriptionDAO.getSubscriptionStatistic (deviceIdsOwnByGroup, isUnsubscribe, tenantId, applicationReleaseDTO.getId());
when getting the stats, we're considering the release id. So the device type constraint will be implicitly satisfied.Yes, otherwise if a scenario like triggering an android application installation to group which have both the windows and android devices assigned to it then those app irrelevant devices (in this case windows) are also being counted for the device count but they are not relevant to that app installation. Here we are getting only the completed, pending and error device count and substract it from the total device count and assign that remainder to the new device count and pass it for the calculation of percentages so, when the device type of the application supported is not considered it will count all the devices relevant to that group so the new device percentage might be wrong.
int getDeviceCount(String groupName, int tenantId) throws GroupManagementDAOException;
int getDeviceCountWithGroup(String groupName, int deviceTypeId, int tenantId) throws GroupManagementDAOException;
Add Java Doc comment
int getDeviceCount(String groupName) throws GroupManagementException;
int getDeviceCountWithGroup(String groupName, int deviceTypeId) throws GroupManagementException;
Add Java Doc comment
try {
GroupManagementDAOFactory.openConnection();
return groupDAO.getDeviceCountWithGroup(groupName,deviceTypeId, tenantId);
} catch (SQLException | GroupManagementDAOException e) {
Please handle this with two exceptions and add two different error messages, it will be useful when we analyze logs if we get an error with this functionality.
16ee68d8a3
to230192f2d9
2 months agodf129651fd
into master 2 months agoReviewers
df129651fd
.