Add Browser Integration to Group Edit page

[varjolintu]

Type of change

• ✅ New feature (non-breaking change which adds functionality)

Description and Context

Adds Browser Integration page to Group Edit page. This allows to set the following options for all entries in the group and its subgroups:

• Skip Auto-Submit for entries
• Hide entries from the browser extension
• Use entries only with HTTP Basic Auth
• Do not use entries with HTTP Basic Auth

Checkboxes are disabled if group level settings are used.

Fixes #1789.
Fixes #3998.

Screenshots

Testing strategy

Manually.

Checklist:

• ✅ I have read the CONTRIBUTING document. [REQUIRED]
• ✅ My code follows the code style of this project. [REQUIRED]
• ✅ All new and existing tests passed. [REQUIRED]
• ✅ I have compiled and verified my code with -DWITH_ASAN=ON. [REQUIRED]

[droidmonkey]

I'm saving this for a future release

[droidmonkey]

@varjolintu do we still want to incorporate this?

[varjolintu]

@droidmonkey Sure, why not. I can make a rebase.

[droidmonkey]

The problem with this implementation is that new entries added to the group do not have the group "desired" settings applied to it. Basically the group settings are a one-shot deal and reapplying them to child entries requires editing the group, checking the box, and pressing OK. This is obviously not the desired intention of these settings.

I think it would be better to store these settings at the group level just like auto-type does. The browser plugin would then exclude entries from groups that have these specific settings applied, depending on the context. This also prevents issues when entries are moved into/out of groups and adding entries to a group with these desired settings.

[varjolintu]

@droidmonkey Good idea to move the option to group level instead.

[varjolintu]

Entry settings also need to be changed to tristate (I think checkboxes will be enough) because the state can be inherited from the group.

[droidmonkey]

My opinion is that group settings override all entries. We make things more complicated by allowing exceptions all over the place.

If anything we should be disabling the entry level checkboxes if the group settings are set

You can disable them and have a tool tip that says the setting is controlled at the group level

[varjolintu]

My opinion is that group settings override all entries. We make things more complicated by allowing exceptions all over the place.

If anything we should be disabling the entry level checkboxes if the group settings are set

You can disable them and have a tool tip that says the setting is controlled at the group level

This was the other option I thought about. However, if group settings are inherited but the setting value is default, we should allow the entry level settings. Disabling them only when the value is set or inherited value differs from the default should work.

[droidmonkey]

Right my assumption is these group settings are meant to be blanket settings across all entries in the group. They should be worded such that they apply to every entry in the group. If the group settings aren't changed then the behavior is as before

[varjolintu]

You are connecting the signals before initializing the UI. The ui elements you connected are nullptr at time of connection.

Got it. This is good to go.

[droidmonkey]

I like the current implementation, simple clean easy to understand. OK to merge this now?

[droidmonkey]

I made some tweaks to wording and positioning of elements. Unfortunately we cannot use the "WriteTriState" into the kdbx, if you do that then those XML elements will be dropped by any client that is no KeePassXC (ie, it is not part of the standard). We need to use the Custom Data of the Group. The benefit to custom data is we can eliminate all the tristate code and polluting the Group class with browser settings.

[varjolintu]

I made some tweaks to wording and positioning of elements. Unfortunately we cannot use the "WriteTriState" into the kdbx, if you do that then those XML elements will be dropped by any client that is no KeePassXC (ie, it is not part of the standard). We need to use the Custom Data of the Group. The benefit to custom data is we can eliminate all the tristate code and polluting the Group class with browser settings.

Ah, ok. Got it. I thought "EnableAutoType" and "EnableSearching" with WriteTriState were also non-standard? This is why I used a similar method.

[varjolintu]

@droidmonkey This should be ready now. Hopefully there's no more findings.

[droidmonkey]

@varjolintu I made the changes necessary to this PR, do a double check for me please.

[varjolintu]

@varjolintu I made the changes necessary to this PR, do a double check for me please.

EDIT: All is working properly. Had some merge errors earlier.

[droidmonkey]

I need to update the tests

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 55.55556% with 92 lines in your changes missing coverage. Please review.

Project coverage is 63.61%. Comparing base (c7cdce6) to head (fdd6718).
Report is 591 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/gui/group/EditGroupWidget.cpp	47.56%	43 Missing ⚠️
src/gui/entry/EditEntryWidget.cpp	73.75%	21 Missing ⚠️
src/browser/BrowserService.cpp	25.00%	15 Missing ⚠️
src/core/Group.cpp	35.00%	13 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #4180      +/-   ##
===========================================
- Coverage    63.63%   63.61%   -0.02%     
===========================================
  Files          330      330              
  Lines        41646    41807     +161     
===========================================
+ Hits         26499    26595      +96     
- Misses       15147    15212      +65     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles