Extend nonMembersCanInteractWithDoors to include fence gates

[Copilot]

The factions.nonMembersCanInteractWithDoors config option only checked for Door and TrapDoor block data types, so fence gates in faction territory were fully protected. Players could cheaply gate off areas with fence gates to bypass the intended door accessibility policy.

Adds org.bukkit.block.data.type.Gate to the existing check:

if (clickedBlock.blockData is Door || clickedBlock.blockData is TrapDoor || clickedBlock.blockData is Gate) {
    return
}

• PlayerInteractListener.kt — Include Gate in the door interaction bypass
• PlayerInteractListenerTest.kt — Add fence gate test mirroring existing door/trapdoor tests
• CONFIG.md — Update description to reflect fence gate coverage

Config key name unchanged for backward compatibility.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• hub.spigotmc.org
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m (dns block)
• jitpack.io
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m (dns block)
• repo.dansplugins.com
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m (dns block)
• repo.extendedclip.com
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m (dns block)
• repo.mikeprimm.com
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m (dns block)
• repo.rpkit.com
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Feature] Config option that allows you to enable outsiders to use doors should extend to more blocks</issue_title>
<issue_description>## Is your feature request related to a problem?
My players have started to gate off important areas of their castles fence gates, as opposed to doors, because the "nonMembersCanInteractWithDoors" configuration option does not extend to fence gates. I think that players should have to commit to using full iron doors if they wish to keep an area secure. Fence gates are inexpensive and shouldn't be fully secure when full wooden doors are not.

Moreover, fence gates are often just used in place of wooden doors in medieval builds, because sometimes they fit nicer than full doors. Especially as a tavern door. So they should be included as part of "nonMembersCanInteractWithDoors".

Describe the solution you'd like

I think that either the "nonMembersCanInteractWithDoors" configuration option should extend to fence gates, or should be replaced with a more configurable option like "nonMemberInteractionBlocks" which would be a list of blocks non-members can interact with while inside a different faction's claims.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Feature] Config option that allows you to enable outsiders to use doors should extend to more blocks #1951

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.

[Copilot]

Pull request overview

Extends the existing “allow non-members to interact with doors” protection exception so it also applies to fence gates, preventing players from bypassing the intended accessibility policy by using gates instead of doors.

Changes:

• Add org.bukkit.block.data.type.Gate to the door/trapdoor interaction bypass condition.
• Add a unit test covering fence gate interaction when the config option is enabled.
• Update CONFIG.md to document that fence gates are included.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/main/kotlin/com/dansplugins/factionsystem/listener/PlayerInteractListener.kt	Extends the interaction bypass condition to include Gate.
src/test/kotlin/com/dansplugins/factionsystem/listener/PlayerInteractListenerTest.kt	Adds a new test validating fence gate interaction is allowed when the config is enabled.
CONFIG.md	Updates config documentation to mention trapdoors and fence gates.

[Copilot]

The nonMembersCanInteractWithDoors early-return happens before the claim/wilderness lookup, so enabling this option currently bypasses wilderness interaction protection as well (and now does so for fence gates too). If the intent is “in faction territory” (per CONFIG.md), consider moving this special-case to after the claim is resolved (only apply it when claim != null).

[Copilot]

Minor: blockData is already read into a local (val blockData = clickedBlock.blockData) earlier in this method. Reusing that variable here would avoid re-fetching clickedBlock.blockData three times and keeps the condition a bit cleaner.

Suggested change

	if (clickedBlock.blockData is Door || clickedBlock.blockData is TrapDoor || clickedBlock.blockData is Gate) {
	if (blockData is Door || blockData is TrapDoor || blockData is Gate) {

[dmccoystephenson]

@copilot address comments

[dmccoystephenson]

@copilot You are a coding agent tasked with resolving all open comments and review threads
on this pull request. Work through every comment systematically and apply the
appropriate code changes.

---

Instructions

1. Discover all comments

• Read every review thread, inline comment, and general PR comment
• Include comments from: Copilot, human reviewers, and any other bots
• Do not skip comments marked as suggestions — apply them if they make sense

2. For each comment, do the following:

• Understand what is being requested or flagged
• Locate the relevant file(s) and line(s)
• Apply the fix directly in code
• If a Copilot suggestion diff is provided, apply it (or an equivalent fix)
• If the comment is ambiguous, use your best judgment and reply in the PR thread or review comment explaining what you did; only add a code comment when explicitly requested or when future maintainers would benefit from it
• After addressing a comment, reply to the thread summarising what you did and mark it as resolved if your environment supports it

3. Types of issues to handle:

• Code quality / style issues (naming, formatting, readability)
• Logic bugs or edge cases flagged by reviewers
• Security concerns (e.g. input validation, secrets, injection risks)
• Performance suggestions
• Missing or incomplete error handling
• Test coverage gaps
• Documentation / comment improvements
• Dependency or import issues

4. Do NOT:

• Dismiss or ignore any comment without acting on it — note that "acting" can also mean replying to the thread with a rationale (e.g., won't fix, already addressed elsewhere) and leaving the code unchanged when appropriate
• Leave TODO comments as a substitute for fixing the issue
• Break existing tests while addressing comments
• Change functionality beyond the scope of what the comment asks for

---

After making changes

• Ensure all existing tests still pass
• Add or update tests if a comment explicitly asks for them, or if a bug fix warrants it
• Double-check that every open thread has been addressed, replied to, and resolved

---

Context

• This PR may contain Copilot-generated review comments — treat these with the same priority as human comments
• If two comments conflict with each other, prefer the human reviewer's intent and document the conflict and resolution in the PR conversation or commit message, not in a code comment
• Commit changes in logical groups if there are many unrelated fixes