Implement hide_all and unhide_all options

[elchininet]

This pull request implements two more options for the configuration:

hide_history_logbook

Hides both, history and logbook in the matched entities.

custom_more_info:
  hide_history_logbook:
    by_entity_id:
      ...
    by_domain:
      ...
    by_device_class:
      ...
    by_glob:
      ...

unhide_history_logbook

Un-hides both, history and logbook in the matched entities.

custom_more_info:
  unhide_history_logbook:
    by_entity_id:
      ...
    by_domain:
      ...
    by_device_class:
      ...
    by_glob:
      ...

[Mariusthvdb]

working beautifully. nice to have such a powerful 'global' option and combining that with the auto_hide_header_history_icon: true option is really cool.

only thing that I wondered about while setting it up in the yaml was the name.

un/hide_all might be not succinct enough, and, might also give the impression it is about the attributes.... I had to look carefully to place it in the correct logical spot.

maybe we should rename it? it can be a bit longer, as it would only be required twice, and not cause yaml clutter.

un/hide_history_logbook ? would be nice next to
un/hide_history
un/hide_logbook

Let me know what you think ?

[elchininet]

Hi @Mariusthvdb,
Renamed both options following your proposal.
Regards

[Mariusthvdb]

tested and working.

much better in the yaml to see what we're doing now.
thx

[Mariusthvdb]

go ahead and merge please. all good for now

[Mariusthvdb]

can you prep the release for this too? Would be nice to get this out in the open asap.

[elchininet]

Hey @Mariusthvdb,

Check that this is enabled and I can try to submit an automatic release:

Maybe you would need to desprotect the branch, but let‘s try it first with the default protection.

[Mariusthvdb]

It is set like that

[elchininet]

The same as the other day:

But now thinking about it, I think that if you create a tag manually using the UI, it will create a relase after that, try to do it.

[Mariusthvdb]

yes, I can do that, but I always need to attach the binary manually.

so not very automatic at all, (only can auto create release notes)

Ill lift the protection for now, and hope you can then auto release?
please check, ive removed most of the ticks...

[elchininet]

yes, I can do that, but I always need to attach the binary manually.
so not very automatic at all, (only can auto create release notes)

Try to create a tag, everything should happen automatically (at the end what I do in local is to create a tag and push it to the repo).

This action creates the release attaching the binary to it:

custom-more-info/.github/workflows/release.yaml

Lines 70 to 76 in c84010c

	- name: Create a release
	uses: softprops/action-gh-release@v1
	with:
	files: |
	custom-more-info.js
	body: |
	${{ steps.build_changelog.outputs.changelog }}

[elchininet]

Ill lift the protection for now, and hope you can then auto release?
please check, ive removed most of the ticks...

Try to create the tag first to see if it works, if not I will push the tag to the repo.

[Mariusthvdb]

I've made the 1.1.0 draft.

now what do I do?

[elchininet]

I've made the 1.1.0 draft.

I meaned just a tag not a release, but now I am seeing that it doesn‘t exist in the UI 😕
Incredible that Github doesn‘t have in the UI something so basic.

https://github.com/orgs/community/discussions/48462

No worries, I‘ll push the tag to the repo

[elchininet]

I am having issues to make it, I need to detect what is wrong in the scripts. Give me some time.

[Mariusthvdb]

sure, take all the time you need, I am truly grateful for all of your efforts ..

[elchininet]

For some reason all the text from the first release is gone 😕
When the new release is created add some text to it.

[elchininet]

For some reason the changelog fails, it seems because the previous release was a manual one it cannot retrieve changes taking into account the previous tag. Please, fill the details by hand, I hope that the next one goes well.

You can protect the branch again.

[elchininet]

I get what is happening, the tag v1.0.0 for some reason belongs to a commit of the previous repository.

There is no anything to compare between those two tags.