Bug: combined projects don't have proper fields from updated stuff like SLM #37

New Issue

serversdown · 2026-03-21T20:28:52-04:00

serversdown commented

2026-03-21 20:28:52 -04:00

Here is the translated version of my issue, my original word vomit is below:

🐛 Issue: Combined Projects Missing Feature Parity

Problem

Currently, when creating a combined project (e.g. vibration + sound), the resulting project does not include the full feature set of both individual project types.

This appears to be caused by features being added over time to individual project types (vibration-only, sound-only), without those features being properly supported or merged into the combined project logic.

Observed issues:

Combined projects behave inconsistently
Some expected functionality is missing depending on feature origin
Feature drift between project types is increasing over time

Likely Root Cause

The system currently treats project type (vibration, sound, combined) as a primary distinction.

This makes it difficult to:

Share features across types
Maintain parity
Extend functionality cleanly

Proposed Direction

Refactor the project model to separate:

Project → container
Modules → capabilities attached to a project

Example (Proposed)

Project
├── Vibration Module
└── Sound Module

Instead of (Current)

Project Type = Vibration / Sound / Combined

Benefits

Eliminates special-case logic for "combined" projects
Keeps features scoped to their respective modules
Prevents feature drift between project types
Enables easier expansion (e.g. dust monitoring, telemetry, etc.)
Simplifies long-term maintenance and UI logic

Open Questions

How tightly coupled are current features to project type?
What would migration look like for existing projects?
Should modules be:
- Defined at project creation only?
- Or dynamically attachable later?

Notes

This is likely a structural issue rather than a one-off bug.
Addressing it now will prevent increasing complexity as more features are added.

WOrd vomit mode:
Maybe needs to be redone completely? Currently when you make a combined project, it doesnt have all the features needed for both. Probably a result of adding features to the individual project systems and them not getting translated to the combined project. Might be good to isolate sound studies from vibration?

Maybe projects refers to the actual project itself, not the type of monitoring being done. Then projects can have "elements" added to them, so like "vibration monitoring section", or "sound monitoring, or one of each."

Here is the translated version of my issue, my original word vomit is below: ## 🐛 Issue: Combined Projects Missing Feature Parity ### Problem Currently, when creating a **combined project** (e.g. vibration + sound), the resulting project does not include the full feature set of both individual project types. This appears to be caused by features being added over time to individual project types (vibration-only, sound-only), without those features being properly supported or merged into the combined project logic. **Observed issues:** - Combined projects behave inconsistently - Some expected functionality is missing depending on feature origin - Feature drift between project types is increasing over time --- ### Likely Root Cause The system currently treats **project type** (vibration, sound, combined) as a primary distinction. This makes it difficult to: - Share features across types - Maintain parity - Extend functionality cleanly --- ### Proposed Direction Refactor the project model to separate: - **Project** → container - **Modules** → capabilities attached to a project #### Example (Proposed) Project ├── Vibration Module └── Sound Module #### Instead of (Current) Project Type = Vibration / Sound / Combined --- ### Benefits - Eliminates special-case logic for "combined" projects - Keeps features scoped to their respective modules - Prevents feature drift between project types - Enables easier expansion (e.g. dust monitoring, telemetry, etc.) - Simplifies long-term maintenance and UI logic --- ### Open Questions - How tightly coupled are current features to project type? - What would migration look like for existing projects? - Should modules be: - Defined at project creation only? - Or dynamically attachable later? --- ### Notes This is likely a structural issue rather than a one-off bug. Addressing it now will prevent increasing complexity as more features are added. WOrd vomit mode: Maybe needs to be redone completely? Currently when you make a combined project, it doesnt have all the features needed for both. Probably a result of adding features to the individual project systems and them not getting translated to the combined project. Might be good to isolate sound studies from vibration? Maybe projects refers to the actual project itself, not the type of monitoring being done. Then projects can have "elements" added to them, so like "vibration monitoring section", or "sound monitoring, or one of each."

serversdown added the Kind/Feature Kind/Enhancement

Priority

Medium

3

labels 2026-03-21 20:28:52 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: serversdown/terra-view#37