Skip to content

Fix: Unable to remove multiline property from field#15242

Merged
calixtus merged 26 commits into
JabRef:mainfrom
pluto-han:fix-for-issue-11897
Apr 4, 2026
Merged

Fix: Unable to remove multiline property from field#15242
calixtus merged 26 commits into
JabRef:mainfrom
pluto-han:fix-for-issue-11897

Conversation

@pluto-han

Copy link
Copy Markdown
Collaborator

Related issues and pull requests

Closes #11897

PR Description

Based on the work in #12040 from @PressJump, I added the resetMultilineFieldsToDefault() method. This method sets MULTILINE_TEXT property of each standard field and nonWrappableFields to default.

Steps to test

  1. Change the "Author", "Volume", "Number" fields to multiline for the "Article" entry type in preferences.
image
  1. Save preferenc and restart jabref. The "Author" field became multiline for all entry types as it is global.

  2. Untick "Author" field and save. "Author" field for all entry types is removed.

image
  1. Click "reset to default". Multiline properties(In this case, "Volume" and "Number") from all fields are removed.
image

Checklist

  • I own the copyright of the code submitted and I license it under the MIT license
  • I manually tested my changes in running JabRef (always required)
  • I added JUnit tests for changes (if applicable)
  • I added screenshots in the PR description (if change is visible to the user)
  • I added a screenshot in the PR description showing a library with a single entry with me as author and as title the issue number
  • I described the change in CHANGELOG.md in a way that can be understood by the average user (if change is visible to the user)
  • I checked the user documentation for up to dateness and submitted a pull request to our user documentation repository

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Fix multiline property removal from fields in preferences

🐞 Bug fix

Grey Divider

Walkthroughs

Description
• Fix multiline property removal from fields in preferences
• Implement resetMultilineFieldsToDefault() to restore standard field defaults
• Add listener to sync multiline changes across all entry types
• Ensure multiline property is properly removed when toggled off
Diagram
flowchart LR
  A["User resets to default"] --> B["resetMultilineFieldsToDefault()"]
  B --> C["Reset standard fields to defaults"]
  B --> D["Reset non-wrappable fields"]
  C --> E["ABSTRACT, COMMENT, REVIEW keep MULTILINE_TEXT"]
  C --> F["Other fields remove MULTILINE_TEXT"]
  D --> G["Update preferences"]
  G --> H["Fields synchronized across entry types"]
Loading

Grey Divider

File Changes

1. jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java ✨ Enhancement +21/-1

Add multiline property listener and reset functionality

• Added BooleanProperty import for multiline property handling
• Replaced direct multilineProperty() binding with createMultilinePropertyListener() to sync changes
 across entry types
• Added call to resetMultilineFieldsToDefault() in resetEntryTypes() method
• Implemented createMultilinePropertyListener() method to propagate multiline changes to fields with
 same name across all entry types

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java


2. jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java ✨ Enhancement +33/-0

Implement reset multiline fields to default functionality

• Added DEFAULT_MULTILINE_FIELDS set containing ABSTRACT, COMMENT, and REVIEW as default multiline
 fields
• Implemented resetMultilineFieldsToDefault() method to reset all fields to default multiline state
• Added resetStandardFieldMultilineToDefaults() to remove MULTILINE_TEXT from non-default fields and
 add it to default ones
• Added getDefaultNonWrappableFields() to retrieve and restore default non-wrappable fields from
 preferences
• Added imports for StandardField and JabRefCliPreferences

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java


3. jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/FieldViewModel.java 🐞 Bug fix +2/-0

Remove multiline property when toggled off

• Added else clause to remove MULTILINE_TEXT property when multiline is set to false
• Ensures proper cleanup of multiline property when toggling off

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/FieldViewModel.java


View more (2)
4. jabgui/src/test/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModelTest.java 🧪 Tests +26/-0

Add test for multiline property reset functionality

• Added imports for Map, FieldProperty, and assertion methods (assertFalse, assertTrue)
• Updated setup() to mock default non-wrappable fields in preferences
• Added comprehensive test resetMultilinePropertyOfStandardFieldsToDefault() verifying reset
 behavior
• Test validates that non-default fields lose MULTILINE_TEXT and default fields retain it after
 reset

jabgui/src/test/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModelTest.java


5. CHANGELOG.md 📝 Documentation +1/-0

Document multiline property fix in changelog

• Added entry documenting fix for multiline property removal issue #11897

CHANGELOG.md


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Feb 28, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

Grey Divider


Action required

1. Leaky multiline listeners 🐞 Bug ➹ Performance
Description
A new ChangeListener is added inside the TableColumn cellValueFactory, which can be evaluated
multiple times (e.g., on refresh/virtualization), causing duplicate listeners and cascading O(N²)
propagation across entry types. This can degrade UI performance and retain objects longer than
intended.
Code

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[R322-330]

+    private BooleanProperty createMultilinePropertyListener(TableColumn.CellDataFeatures<FieldViewModel, Boolean> item) {
+        BooleanProperty property = item.getValue().multilineProperty();
+        property.addListener((obs, wasSelected, isSelected) -> {
+            viewModel.entryTypes().forEach(typeViewModel -> {
+                typeViewModel.fields().stream()
+                             .filter(field -> field.displayNameProperty().get().equals(item.getValue().displayNameProperty().get()))
+                             .forEach(field -> field.multilineProperty().set(isSelected));
+            });
+        });
Evidence
The multiline column now uses a value factory that installs a listener on every invocation. The
listener also sets multiline on all matching fields, which triggers their listeners too, amplifying
work. The table explicitly calls refresh during editing and reset flows, increasing the chance the
value factory is re-evaluated and listeners multiply.

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[187-189]
jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[322-330]
jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[159-165]
jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[300-313]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`CustomEntryTypesTab#createMultilinePropertyListener` adds a listener inside the TableColumn `cellValueFactory`. JavaFX may call the value factory multiple times (refresh, virtualization, re-skin), which can attach multiple listeners to the same `BooleanProperty`. Each listener then propagates changes to all entry types, which can also trigger other listeners, causing duplicated work and potential memory/perf issues.
## Issue Context
- The multiline column is configured with `setCellValueFactory(this::createMultilinePropertyListener)`.
- `createMultilinePropertyListener` unconditionally calls `property.addListener(...)`.
- The listener sets multiline on many other `FieldViewModel`s, which may also have listeners.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[187-189]
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[322-331]
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[159-180]
## Suggested implementation directions (pick one)
1) **Install-once + reentrancy guard (smallest change):**
- Add an `IdentityHashMap`-backed `Set&amp;lt;FieldViewModel&amp;gt;` to track listener installation.
- In `createMultilinePropertyListener`, only `addListener` if not yet installed.
- Add a `boolean`/`AtomicBoolean` guard to prevent re-entrant propagation while applying updates.
2) **Central coordinator in ViewModel (cleaner):**
- Move propagation logic into `CustomEntryTypesTabViewModel` (or a helper) that registers listeners once when `EntryTypeViewModel`s/fields are created.
- Coordinate updates by field identity (prefer underlying `Field` name vs displayName), and suppress re-entrant updates.
3) **Shared property per field name (best UX/perf):**
- Maintain `Map&amp;lt;String, BooleanProperty&amp;gt;` for multiline state and bind each `FieldViewModel` to the shared property for that field name.
- This eliminates fan-out listeners entirely.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. Hard-coded default set🐞 Bug ≡ Correctness
Description
Reset logic duplicates knowledge of which StandardFields are multiline by default via a local
hard-coded set. If StandardField defaults change later, reset-to-default may silently become
incorrect.
Code

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java[R237-244]

+    private void resetStandardFieldMultilineToDefaults() {
+        for (StandardField field : StandardField.values()) {
+            if (DEFAULT_MULTILINE_FIELDS.contains(field)) {
+                field.getProperties().add(FieldProperty.MULTILINE_TEXT);
+            } else {
+                field.getProperties().remove(FieldProperty.MULTILINE_TEXT);
+            }
+        }
Evidence
The reset method depends on a hard-coded set of default multiline fields. StandardField itself
declares which fields are multiline by default; duplicating this in the view model risks divergence
when StandardField evolves.

jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java[54-58]
jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java[237-244]
jablib/src/main/java/org/jabref/model/entry/field/StandardField.java[13-33]
jablib/src/main/java/org/jabref/model/entry/field/StandardField.java[106-109]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`CustomEntryTypesTabViewModel` hard-codes the list of StandardFields that should have `MULTILINE_TEXT` by default. This duplicates StandardField’s own default properties and can silently diverge if StandardField changes.
## Issue Context
- StandardField defines defaults via constructor properties.
- Reset logic uses `DEFAULT_MULTILINE_FIELDS` to decide add/remove MULTILINE_TEXT.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java[54-58]
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModel.java[237-245]
- jablib/src/main/java/org/jabref/model/entry/field/StandardField.java[13-33]
## Suggested fix
- Add a single source of truth in `StandardField`, e.g. `public static Set&amp;lt;StandardField&amp;gt; defaultMultilineFields()` or `DEFAULT_MULTILINE_FIELDS`.
- Update `CustomEntryTypesTabViewModel` to use that constant/method instead of maintaining its own list.
- Optionally add/adjust a unit test to ensure the reset uses the StandardField-provided defaults.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Test cleanup not guaranteed 🐞 Bug ≡ Correctness
Description
The new unit test mutates global enum state (StandardField properties) and relies on subsequent
lines to restore state. If an assertion fails mid-test, the JVM can be left in a mutated state,
potentially breaking other tests.
Code

jabgui/src/test/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModelTest.java[R103-119]

+    void resetMultilinePropertyOfStandardFieldsToDefault() {
+        CustomEntryTypesTabViewModel model = new CustomEntryTypesTabViewModel(BibDatabaseMode.BIBLATEX, entryTypesManager, mock(DialogService.class), preferences);
+        model.resetMultilineFieldsToDefault();
+
+        StandardField fieldTitle = StandardField.TITLE;
+        assertFalse(fieldTitle.getProperties().contains(FieldProperty.MULTILINE_TEXT));
+        fieldTitle.getProperties().add(FieldProperty.MULTILINE_TEXT);
+        assertTrue(fieldTitle.getProperties().contains(FieldProperty.MULTILINE_TEXT));
+        model.resetMultilineFieldsToDefault();
+        assertFalse(fieldTitle.getProperties().contains(FieldProperty.MULTILINE_TEXT));
+
+        StandardField fieldAbstract = StandardField.ABSTRACT;
+        assertTrue(fieldAbstract.getProperties().contains(FieldProperty.MULTILINE_TEXT));
+        fieldAbstract.getProperties().remove(FieldProperty.MULTILINE_TEXT);
+        assertFalse(fieldAbstract.getProperties().contains(FieldProperty.MULTILINE_TEXT));
+        model.resetMultilineFieldsToDefault();
+        assertTrue(fieldAbstract.getProperties().contains(FieldProperty.MULTILINE_TEXT));
Evidence
StandardField properties are stored on enum singletons and are mutable. The test mutates them
directly and does not protect restoration with try/finally or @AfterEach, so failures can leak
state.

jabgui/src/test/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModelTest.java[103-119]
jablib/src/main/java/org/jabref/model/entry/field/Field.java[10-14]
jablib/src/main/java/org/jabref/model/entry/field/StandardField.java[155-172]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test mutates `StandardField` enum properties (global JVM state). If the test fails before the final reset calls, the mutated state may leak into subsequent tests.
## Issue Context
- `StandardField` stores a mutable `EnumSet&amp;lt;FieldProperty&amp;gt;` per enum constant.
- The test modifies that set directly.
## Fix Focus Areas
- jabgui/src/test/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTabViewModelTest.java[103-120]
## Suggested fix
- Capture original MULTILINE_TEXT presence (or full properties snapshot) for the fields you mutate.
- Use `try/finally` to restore state, e.g.:
- `boolean titleHad = StandardField.TITLE.getProperties().contains(MULTILINE_TEXT);`
- `finally { restorePresence(StandardField.TITLE, titleHad); ... }`
- Alternatively add `@AfterEach` that restores the affected fields back to their original state (or calls a reset method in a guaranteed-cleanup way).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

@github-actions github-actions Bot added the good second issue Issues that involve a tour of two or three interweaved components in JabRef label Feb 28, 2026
Comment on lines +322 to +330
private BooleanProperty createMultilinePropertyListener(TableColumn.CellDataFeatures<FieldViewModel, Boolean> item) {
BooleanProperty property = item.getValue().multilineProperty();
property.addListener((obs, wasSelected, isSelected) -> {
viewModel.entryTypes().forEach(typeViewModel -> {
typeViewModel.fields().stream()
.filter(field -> field.displayNameProperty().get().equals(item.getValue().displayNameProperty().get()))
.forEach(field -> field.multilineProperty().set(isSelected));
});
});

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Leaky multiline listeners 🐞 Bug ➹ Performance

A new ChangeListener is added inside the TableColumn cellValueFactory, which can be evaluated
multiple times (e.g., on refresh/virtualization), causing duplicate listeners and cascading O(N²)
propagation across entry types. This can degrade UI performance and retain objects longer than
intended.
Agent Prompt
## Issue description
`CustomEntryTypesTab#createMultilinePropertyListener` adds a listener inside the TableColumn `cellValueFactory`. JavaFX may call the value factory multiple times (refresh, virtualization, re-skin), which can attach multiple listeners to the same `BooleanProperty`. Each listener then propagates changes to all entry types, which can also trigger other listeners, causing duplicated work and potential memory/perf issues.

## Issue Context
- The multiline column is configured with `setCellValueFactory(this::createMultilinePropertyListener)`.
- `createMultilinePropertyListener` unconditionally calls `property.addListener(...)`.
- The listener sets multiline on many other `FieldViewModel`s, which may also have listeners.

## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[187-189]
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[322-331]
- jabgui/src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java[159-180]

## Suggested implementation directions (pick one)
1) **Install-once + reentrancy guard (smallest change):**
   - Add an `IdentityHashMap`-backed `Set<FieldViewModel>` to track listener installation.
   - In `createMultilinePropertyListener`, only `addListener` if not yet installed.
   - Add a `boolean`/`AtomicBoolean` guard to prevent re-entrant propagation while applying updates.

2) **Central coordinator in ViewModel (cleaner):**
   - Move propagation logic into `CustomEntryTypesTabViewModel` (or a helper) that registers listeners once when `EntryTypeViewModel`s/fields are created.
   - Coordinate updates by field identity (prefer underlying `Field` name vs displayName), and suppress re-entrant updates.

3) **Shared property per field name (best UX/perf):**
   - Maintain `Map<String, BooleanProperty>` for multiline state and bind each `FieldViewModel` to the shared property for that field name.
   - This eliminates fan-out listeners entirely.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@github-actions github-actions Bot added the status: changes-required Pull requests that are not yet complete label Feb 28, 2026
@testlens-app

This comment has been minimized.

@testlens-app

This comment has been minimized.

@github-actions github-actions Bot added status: no-bot-comments and removed status: changes-required Pull requests that are not yet complete labels Feb 28, 2026
@koppor

koppor commented Mar 1, 2026

Copy link
Copy Markdown
Member

Related PR: #11230

private final StringProperty newFieldToAdd = new SimpleStringProperty("");
private final ObservableList<EntryTypeViewModel> entryTypesWithFields = FXCollections.observableArrayList(extractor -> new Observable[] {extractor.entryType(), extractor.fields()});
private final List<BibEntryType> entryTypesToDelete = new ArrayList<>();
private final Set<StandardField> DEFAULT_MULTILINE_FIELDS = Set.of(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest move this into StandardFields as a static variable so it's more easily adaptable.

@pluto-han pluto-han Mar 1, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your review. I have set it as a static variable

}

private List<Field> getDefaultNonWrappableFields() {
Object defaultNonWrappableFields = preferences.getDefaults().get(JabRefCliPreferences.NON_WRAPPABLE_FIELDS);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@calixtus Is there a better option to get a default value of a specifci preference?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conversion to new preferences must be continued in JabRefCliPreferences following the example for JabRefGuiPreferences (see #14400 ).

Direct access to JabRefCliPreferences is not acceptable anymore.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conversion to new preferences must be continued in JabRefCliPreferences following the example for JabRefGuiPreferences (see #14400 ).

Hi @calixtus , do you mean that getDefaultValue() should be done in a specific preference class(in this case FieldPreference), instead of directly accessing JabRefCliPreference.getDefaults()?

And according to #14400, I think we should also reset FieldPreference? For example, remove default values from JabRefCliPreference and add get/set default methods in FieldPreference.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JabRefPreferences.getDefaults is to be removed. Follow the many example prs that were already made.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I have removed getDefaults in FieldPreference, is there anything I should do?

@testlens-app

This comment has been minimized.

fieldPreferences = mock(FieldPreferences.class);
when(fieldPreferences.getNonWrappableFields()).thenReturn(FXCollections.observableArrayList());
when(preferences.getFieldPreferences()).thenReturn(fieldPreferences);
when(preferences.getDefaults()).thenReturn(Map.of(JabRefCliPreferences.NON_WRAPPABLE_FIELDS, "pdf;ps;url;doi;file;isbn;issn"));

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be part of defaults in a PreferencesObject

@testlens-app

This comment has been minimized.

@testlens-app

This comment has been minimized.

@testlens-app

This comment has been minimized.

@pluto-han

Copy link
Copy Markdown
Collaborator Author

Hi devs, I made some resettings to FieldPreference according to the examples in #14400. Now default value can only be retrieved from FieldPreference.

Moreover, I found that "reset to default" button works as expected, but "reset preference" would not reset multiline property. I fixed that issue by adding resetMultilineFieldsToDefault() in CustomEntryTypesTabViewModel#setValue()

@testlens-app

This comment has been minimized.

@testlens-app

This comment has been minimized.

subhramit
subhramit previously approved these changes Mar 26, 2026

@subhramit subhramit left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

@testlens-app

This comment has been minimized.

@github-actions github-actions Bot added status: changes-required Pull requests that are not yet complete and removed status: no-bot-comments labels Mar 28, 2026
@testlens-app

This comment has been minimized.

@github-actions github-actions Bot added status: no-bot-comments and removed status: changes-required Pull requests that are not yet complete labels Mar 28, 2026
@pluto-han

Copy link
Copy Markdown
Collaborator Author

Resolved conflicts with #15395

@testlens-app

testlens-app Bot commented Mar 28, 2026

Copy link
Copy Markdown

✅ All tests passed ✅

🏷️ Commit: c0c5811
▶️ Tests: 10207 executed
⚪️ Checks: 52/52 completed


Learn more about TestLens at testlens.app.

subhramit
subhramit previously approved these changes Mar 28, 2026
@github-actions github-actions Bot added status: changes-required Pull requests that are not yet complete and removed status: no-bot-comments labels Mar 29, 2026
@subhramit subhramit dismissed their stale review March 29, 2026 10:25

Changes pending

@calixtus

calixtus commented Apr 4, 2026

Copy link
Copy Markdown
Member

LGTM, lets move forward

@calixtus calixtus enabled auto-merge April 4, 2026 07:11
@github-actions github-actions Bot added status: no-bot-comments and removed status: changes-required Pull requests that are not yet complete labels Apr 4, 2026
@calixtus calixtus added this pull request to the merge queue Apr 4, 2026
@github-actions github-actions Bot added the status: to-be-merged PRs which are accepted and should go into the merge-queue. label Apr 4, 2026
Merged via the queue into JabRef:main with commit 8f513c1 Apr 4, 2026
53 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

good second issue Issues that involve a tour of two or three interweaved components in JabRef status: no-bot-comments status: to-be-merged PRs which are accepted and should go into the merge-queue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Entry types preferences: Unable to remove multiline property from field

5 participants