-
-
Notifications
You must be signed in to change notification settings - Fork 679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve installed applications list to application names in last notification allow list #3683
Comments
There is a big problem with this request, the application names are not unique and therefore you can have multiple apps with the name Map. Package Name is meant to be unique which is why it is shown. |
@dshokouhi that's a good point but I'm not sure showing only the Application IDs is suitable either. As a technical/power user I struggle to determine the correct package name and have to resort to reading URLs from the play store. There's no way I could explain to a less technical user how to do this. This would help differentiate between apps with duplicate names:
Automate for example has a rather nice package selector which includes the name, ID and icon to help find the correct app: |
This is expected behavior and everywhere else in the application that we allow users to interact with other apps we also expect the user to know the package name because thats required. Even our last used app sensor reports the state as the package name. We use it everywhere. The other issue is that not all internal apps have an app name so listing it twice will not be good behavior either. We have to list system apps as the messaging app and other apps can be installed as system apps. We can look into adding the application name to make it easier to identify but the ID is not considered secondary information here. |
For sensor values I think ID makes absolute sense. The uniqueness is required in order to differentiate between apps in automations that, as you say, might have the same name. It's a good point on notifications from system apps as well and I have seen app lists before where apps have no name so must display the ID instead. There are quite a lot of apps with package lists using this pattern (e.g. Titanium Backup). If the name is there it will help massively, but I think it would be easier if name was the primary information and how the list is ordered, even if it is stored by ID. Especially since the app name is shown when you expand the notification from an app. Automate in the example above is very similar to HA using package IDs in the automations. This is a new PR though so can see what people think, or implement it with ID as primary and name as secondary which might prompt feedback. |
Labels can be different from the stored value for sensor settings.
Not sure I agree, for something like the next alarm allow list ("I only want to see alarms from my clock app") you could use this without any technical background and it would be secondary. As we already have a system in place for different labels, I've adjusted this dialog to use "Application name (package name)" or "Package name" if there is no application name. Not the same as the fully custom dialog in the screenshot (that would require a lot of reworking) but I think it is an improvement. See the linked PR above. |
Is your feature request related to a problem? Please describe.
When configuring the Last Notification sensor, the allow list displays the list of installed applications by their ID. This can make it quite difficult to find the correct apps.
I am unsure if the "Allow list" functionality is present for other sensors.
Describe the solution you'd like
The apps should be resolved to their names making them easier to find, potentially with the ID displayed as secondary information (e.g. smaller, muted text).
Describe alternatives you've considered, if any
At the moment I have to look for useful information in the ID but this is not always present. If not present, I have to open the google play store page for the app in a web browser. The ID is then visible in the URL.
Additional context
Companion app version: 2023.7.5-full
HA Version: 2023.7.1
Related to #3684
The text was updated successfully, but these errors were encountered: