[FEATURE] Persistent mailbox tree, folder creation and drag-and-drop filing for NoSync accounts

Open
  • Is something wrong?
#343 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust
Domain
backend, database, frontend

Research direction

The proposal names the Search page, NoSync mailbox creation, and the envelope and attachment mailbox indexes, but gives no source files or tests. Start by tracing how NoSync EML import creates mailboxes and how search results and mailbox counters are built. Done means reviewed support for the proposed folder creation and message filing flows, with index and counter updates, permissions, and NoSync-only behavior; the issue says the proof of concept is available from the author.

Written by the indexing model from the issue text.

Description

enhancement

Feature proposal

Hi,

While testing Bichon 2.0.1 with a NoSync archive, I found that the existing mailbox model already works well for organizing imported messages into hierarchical paths such as:

Projects/Project A
Projects/Project B
Administrative/Invoices
Administrative/Contracts

However, once many messages are archived, managing these folders mainly through search filters becomes less convenient.

I built a working proof of concept on Bichon 2.0.1 that adds a persistent mailbox tree to the Search page and extends it with folder creation and drag-and-drop message filing.

Example use case

Imagine a small Purchasing department using a shared NoSync archive.

Several employees archive emails from Thunderbird into Bichon.

Their archive could look like:

Purchasing
├── 00 - To classify
├── Suppliers
│ ├── Supplier A
│ └── Supplier B
├── Orders
│ ├── 2026
│ └── 2027
├── Contracts
└── Archives

Most incoming emails are initially archived into "00 - To classify".

Later, users reviewing the archive need a quick way to move messages into the appropriate folder.

Without a persistent folder tree, users have to repeatedly use mailbox filters to navigate the archive.

With the proposed interface, they can simply drag an email from the search results and drop it onto:

Suppliers / Supplier A

This makes Bichon behave more like an archive/document classification system while keeping the current NoSync model.

Proposed features

Persistent mailbox tree

Display the mailbox hierarchy permanently on the left side of the Search page.

Example:

Archives
├── All messages
├── 00 - To classify
├── Administrative
├── Projects
│ ├── Project A
│ └── Project B
└── Archives
└── 2026

Clicking a mailbox filters the current search results.

Parent folders can also represent all descendant mailboxes.

Folder creation

Allow users to create folders and nested folders directly from the WebUI.

Example:

Projects
└── New Project

would create the NoSync mailbox path:

Projects/New Project

Bichon already creates missing NoSync mailboxes during EML import, so the same mailbox creation logic could potentially be reused.

This feature could remain limited to NoSync accounts.

Drag-and-drop message filing

Allow one or multiple messages to be dragged from the Search results onto a mailbox.

Example:

[Email]
↓
Projects / Project A

The server would reassign the archived message to the target mailbox.

If several messages are selected, dragging one selected message could move the entire selection.

Mailbox counters

After a move, mailbox message counters should be refreshed automatically.

Permissions

Folder creation could reuse:

data:import:batch

since NoSync imports can already implicitly create mailboxes.

Moving existing archived messages modifies archive metadata, so the current:

data:manage

permission could be used.

Alternatively, a more restrictive permission such as:

data:move

could be introduced if finer-grained access control is preferred.

NoSync only

For an initial implementation, I would suggest limiting these features to NoSync accounts.

IMAP accounts should remain unchanged, since moving an archived IMAP message could have different synchronization semantics.

Possible server-side move API

For example:

POST /api/v1/move-messages

{
"account_id": 12,
"envelope_ids": [
"message-id-1",
"message-id-2"
],
"target_mailbox_id": 12345
}

The implementation should keep both archive indexes consistent:

  • envelope mailbox_id
  • attachment mailbox_id
  • deduplication cache
  • mailbox message counters

The raw EML/blob does not need to be duplicated or moved.

Possible folder creation API

For example:

POST /api/v1/create-mailbox

{
"account_id": 12,
"name": "Projects/Project C"
}

Only NoSync accounts would accept this operation.

UX considerations

Drag and drop should not be the only way to move messages.

A "Move to folder..." action could also be added to row or bulk actions for keyboard accessibility and users who prefer not to use drag and drop.

Possible behavior:

  • drag one message -> move one message
  • select several messages + drag -> move the selection
  • highlight the target mailbox while dragging
  • reject cross-account moves
  • no-op when dropping into the current mailbox
  • refresh search results and mailbox counters after the move

Proof of concept

I currently have a working proof of concept running on Bichon 2.0.1 with:

  • persistent mailbox sidebar
  • hierarchical NoSync folders
  • folder and subfolder creation
  • message drag and drop
  • multi-message drag and drop
  • mailbox counter updates
  • NoSync-only server validation
  • permission checks
  • envelope and attachment index updates

The proof of concept was implemented without changing the existing storage format.

I should mention that I am not a software developer. My background is systems and network administration, and I used AI assistance to help understand the Bichon codebase, implement the proof of concept, and troubleshoot the build.

I have tested the resulting implementation on a Bichon 2.0.1 instance, but I would of course expect the code to require review, cleanup, and adjustments to match the project's coding standards.

If this direction fits the project, I would be happy to share the current implementation and help test a cleaner upstream version.

Dominant language
Rust
Stars
2.1k
Forks
91
Avg merge
14h 54m
Merged PRs (30d)
6

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rustmailer/bichon

All issues in rustmailer/bichon

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.