flytegg / flytegg/plugin-portal

Allow excluding specific plugins from updateAll

Open
#102 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Kotlin
Stars
92
Forks
15
Avg merge
49m
Merged PRs (30d)
4

Description

## Summary
Add a per-plugin way to exclude selected plugins from `/pp updateAll`, while keeping them tracked by Plugin Portal for listing, recognition, and manual updates.

Credit to [Zoriot](https://github.com/Zoriot) for the report.

## Problem
Some server owners need to hold back a specific plugin version even when newer marketplace versions exist. Today `/pp updateAll` considers every tracked local plugin and has no per-plugin skip/pin mechanism. The only workaround is to stop tracking the plugin in Plugin Portal metadata, which is not ideal because it also loses normal Plugin Portal management context.

A concrete example is a plugin releasing an update that breaks worlds or server behavior, where the owner still wants to update other plugins safely.

## Proposed behavior
- Add a per-plugin update exclusion or pin flag for locally tracked plugins.
- `/pp updateAll` should skip excluded plugins by default.
- Single-plugin `/pp update ` should still allow a deliberate manual update, or should require an explicit force flag if that is safer.
- The skipped plugins should be shown in updateAll output so operators understand why they were not updated.

## Possible command surface
One of these would work:

- `/pp update ignore ` and `/pp update unignore `
- `/pp pin ` and `/pp unpin `
- `/pp updateAll --include-ignored` for deliberate override

## Implementation notes
- Store the setting with the local plugin tracking data, for example an `updateIgnored` or `pinned` boolean on `LocalPlugin`.
- Preserve backwards compatibility with existing `plugins.json` entries that do not include the new field.
- Filter ignored plugins before building the `/pp updateAll` update plan.
- Keep the plugin visible in `/pp list`, recognition, import/export, and manual update flows.

Contributor guide

Open the contributing guide

Research direction

Start by tracing the LocalPlugin tracking data, existing plugins.json entries, and the /pp updateAll flow. Define how the new per-plugin flag remains backward-compatible, is exposed through the chosen command surface, and is preserved in listing, recognition, import/export, and manual updates. Done means excluded plugins are skipped and explained by updateAll while still remaining tracked and manually updateable.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin
Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.