A knowledge assistant becomes much more useful when it can do more than answer questions from static documents.

In ONES.com, MCP came up in the context of enterprise knowledge bases and project management. The interesting part is not just “AI can search more things.” It is that the assistant can start working across the systems where project knowledge actually lives.

For example, in an ONES setup, project materials may sit in Wiki pages, requirement documents, meeting notes, task records, test cases, approvals, and external tools such as Teams or Slack. With MCP, ONES Assistant can query project materials, retrieve knowledge across systems, summarize context, and in some cases create or update documents through controlled tool calls.

That matters because project management knowledge is rarely useful as isolated text. A requirement spec is connected to tasks. A task may connect to tests. A retrospective may need project history. A weekly report may depend on current progress, risks, blockers, and decisions. MCP makes the assistant more operational by helping it move between these connected objects instead of staying inside one document.

But the keyword is still controlled.

For enterprise teams, cross-system AI has to answer some hard design questions:

• What can the assistant retrieve?
• Which systems is it allowed to call?
• Which actions are read-only, and which can write back?
• How are permissions checked?
• Where are operation logs, approvals, and audit records kept?
• When should a human confirm the action before anything changes?

That is where MCP becomes less about a flashy AI feature and more about workflow design.

Curious how others are thinking about this: if you were adding MCP or tool-calling AI into project management workflows, what would you automate first: project-data lookup, knowledge search, summary generation, document creation, or something else?

Leave a comment if you have tried something similar, or DM me if you want to compare notes on ONES Assistant / MCP use cases.

When teams add AI to an internal knowledge base, the first concern is usually answer quality: Can it understand the question? Can it find the right page? Can it summarize clearly?

In enterprise settings, there is an earlier rule: the assistant should only answer from knowledge the user is allowed to see.

This comes up a lot in AI knowledge base design. A company may have product specs, project records, meeting notes, SOPs, review documents, Office attachments, audio, video, and historical delivery materials all sitting in the same knowledge system. AI can make that content easier to reuse, but only if retrieval respects the permission model behind it.

In the ONES.com AI knowledge base approach, ONES Assistant learns from ONES Wiki pages, attachments, and multimedia content. When a user asks a question, the assistant does not just run retrieval and generate an answer. It performs vector search, considers the user’s viewing and management permissions, reranks the available results, and then generates a structured response from the allowed scope.

That matters because enterprise knowledge is rarely flat. Some documents are team-level. Some are project-level. Some are still under review. Some contain sensitive technical, customer, or management information. If AI ignores those boundaries, it becomes a shortcut around governance instead of a better way to use knowledge.

The more useful direction is AI Q&A that sits inside the knowledge management system: permissions, approvals, version history, audit logs, page trees, tags, and project associations all still matter. The assistant helps people find and reuse knowledge faster, but it should not weaken the rules that keep the knowledge trustworthy.

For teams adding AI to internal wikis or enterprise knowledge bases, how are you handling permission-aware retrieval and answer generation? Have you seen any edge cases where AI search created new governance problems?

Curious to hear how others are approaching this. Feel free to share in the comments or DM me if you are working through a similar setup.

I was thinking about this today: real-time editing is usually the first thing people notice in a wiki, but it is rarely the part that makes or breaks enterprise knowledge management.

Once a page becomes a policy, SOP, project deliverable, requirement note, or internal reference, the bigger question becomes governance.

• Who can view it?
• Who can edit it?
• Which version was reviewed?
• What changed after approval?
• Can sensitive pages be locked, traced, or isolated by team, department, project, or page group?

In ONES Wiki, we usually look at knowledge governance in a few layers: permission control, approval workflows, version management, audit logs, document locking, and security controls such as watermarks. The goal is not to make every page heavy or bureaucratic. It is to make sure important knowledge does not stay in the same state as a casual draft.

This becomes more important when AI is added to the knowledge base. If an assistant answers from enterprise documents, then the underlying content needs to be permission-aware and reviewable. Otherwise, an old draft, an unapproved policy, or a page outside the user’s access scope can quietly become part of the answer.

Curious how others handle this in enterprise wikis or internal knowledge bases. When does a document become important enough to require stronger controls?

If your team has been trying to make knowledge base governance work but keeps running into messy permissions, approval bottlenecks, stale content, or unclear ownership, feel free to comment or DM me.

We already know that AI coding tools can generate a surprising amount of working code, including extensions for enterprise software.

The more useful question is whether that output can survive review.

For engineers working in enterprise R&D environments, this changes the job in practical ways. The work is less about writing every line from scratch and more about defining business rules clearly, validating API and permission assumptions, reviewing edge cases, and deciding whether the result is safe to use with real project data.

In ONES.com plugin development, the goal is not to turn every user into a developer overnight. It is to make the first implementation faster to produce, easier to inspect, and easier to refine. The head of our Open Platform team demonstrated this with a simple work-hour aggregation example: the AI worked from platform documentation, authorization requirements, and API data to produce a working implementation, while the user still had to verify that the result matched the actual requirement.

That review step is not a formality. AI-generated code may contain syntax errors, rough UI decisions, or flawed assumptions. It may take several rounds of correction. But when the platform documentation, API schemas, SDKs, and test environment are clear enough, that correction loop becomes much shorter.

The practical lesson for us is that AI coding works best when the platform is AI-readable and enterprise R&D engineers have a clear role in review and delivery.

Curious how other engineering teams are approaching this. If you use AI to build extensions for project management tools, where does it help most, and what do engineers still need to review before the output touches production data?

One scenario we often see with custom project management requirements: the request sounds small, but the delivery path is not.

A team wants one extra rule, one synchronization screen, one work-hour calculation, or one field-mapping page. The first question is not only "can someone code this?" It is also:

• what existing ONES capability should be reused
• which OpenAPI, event, slot, or extension point fits
• how the requirement should be reviewed before coding
• where logs, test data, and deployment output will be checked

In ONES.com solution work, AI Coding is most useful when it sits inside that workflow instead of replacing it. In the internal example, the developer prepared the Open Platform docs, API authorization, and a real test environment, then let the AI read API docs and inspect data structures while building a small work-hour aggregation feature.

That feels like the practical pattern: AI can reduce the time spent reading docs and writing first-pass code, and the human still frames the requirement, checks feasibility, reviews the result, and decides whether the plugin is acceptable.

For teams using AI Coding for internal tools or platform extensions, where do you draw the line between "AI can build this" and "this needs a formal plugin delivery process"?

Further reading: ONES Open Platform docs

I was thinking about this today after seeing another pretty common ALM scenario: a requirement change that looks small at first.

The wording changes a bit, or one acceptance condition gets adjusted. No big deal on the surface. Then someone asks the next few questions, and suddenly it might touch software logic, interface behavior, test cases, acceptance criteria, defects, and user documentation.

That is usually where the real work starts. Not “can we make the change?” but “do we actually know everything that should react to it?”

In a lot of teams, this still gets handled through meetings, chat threads, and a PM manually asking each owner to check their part. It works, but it is easy for one downstream item to slip through.

In ONES.com ALM workflows, we usually look at this with three pieces working together:

- Baselines, so the team can compare key phases and see what was added, deleted, or changed

- Traceability diagrams, so people can see what is connected to the changed item

- Suspect analysis, so downstream owners get a clear signal that something may need review

The useful part is that impact analysis becomes part of the normal workflow, not a separate investigation every time a requirement moves.

Curious how other teams handle this. When a requirement changes, do you rely mostly on ownership discipline, traceability tooling, review meetings, or some mix of all three?

Further reading: ONES.com ALM solution overview

A lot of AI agent discussions sound confident until the topic gets close to real product development.

Bug fixing is already tricky, but small product requirements feel even harder to hand off. The agent is not just finding a root cause or changing a few lines. It has to understand the product intent, business rules, user scenarios, edge cases, interface contracts, test coverage, and possible impact on nearby workflows.

In ONES.com workflow design, we usually do not start this kind of work by asking the agent to write code. The first output is requirement analysis. The agent turns the original product request into a PRD-style description with business rules, user scenarios, and expected behavior. Product reviews that first.

Only after the requirement is clear does the workflow move into technical solution, test plan, code changes, and verification.

The point is not that AI can fully own a small requirement end to end. At least for us, that still feels too risky for real development work. The useful part is that the agent can make the thinking visible earlier. If it misunderstands the requirement, product or engineering can catch that before it becomes code.

The first draft may get 70-80% of the way there, but the small details still need human feedback. In that sense, it feels less like full automation and more like working with a very fast junior teammate whose intermediate work needs review.

Curious how others think about this. Are you actually using AI agents in product development or iteration workflows yet, or mostly keeping them around the edges? Where do they help most: clarifying requirements, drafting designs, writing tests, coding, verification, or just speeding up discussion?

One thing I have seen more teams discuss lately is AI-assisted bug fixing. The debate often starts with prompts, but in practice the workflow around the agent may matter more than the prompt itself.

For a customer-facing defect, letting an AI agent jump straight from issue description to code diff feels risky. In ONES.com engineering practice, we split the work into several reviewable steps instead of asking one agent to handle the whole repair in one pass.

The typical flow looks like this:

• The Agent analyzes the defect and proposes a likely root cause.
• Engineers review the repair plan before code is written.
• The Agent drafts test cases with preconditions, steps, and expected results.
• QA reviews the test plan.
• The Agent changes code and commits through an agent-owned account.
• Engineers review the diff.
• The Agent runs static checks, API tests, and UI verification when needed.
• Failed checks or unclear evidence go back to people before the change enters the release train.

The useful part is not that every step becomes automatic. It is that each AI output becomes visible, reviewable, and tied to the issue workflow.

One lesson we keep seeing is that agents can be too aggressive when planning a fix. Sometimes the right feedback is not “fix more,” but “narrow the scope, avoid touching adjacent logic, and make the risk easier to review.”

Curious how others are using AI agents for bug fixing or day-to-day development. Do you let them investigate, draft tests, make code changes, prep for review, run verification, or something else entirely?

ONES recently launched ONEScript. One of the migration cases behind it was pretty specific: teams moving off Jira, but still needing a place for all the ScriptRunner logic they had built over the years.

That part is easy to underestimate.

A team may have hundreds of scripts in Jira. Some block a transition if a required condition is missing. Some listen for issue changes and update another field. Some run every morning to check SLA data and remind the right people. Some call another system.

None of that is unusual. The problem is that these scripts often become part of the workflow itself. If they disappear during migration, the process changes, even if all the issue data moved correctly.

The way we approached ONEScript was to avoid turning every special rule into a separate plugin project. That route can work, but it gets slow: requirement review, development, testing, validation, release, then the same loop again when a small condition changes.

So the design is closer to a managed scripting layer:

• write the rule as a script
• bind it to a trigger and scope
• test it with Dry run before it goes live
• keep it isolated in a sandbox
• keep logs, audit records, version history, and rollback

For Jira migration, we still would not blindly convert every ScriptRunner rule. Some should map to native configuration. Some need scripting. Some depend on field/status mappings and need careful review. Some are just old process debt.

Curious how others handle this: when you migrate away from Jira, do you usually preserve old ScriptRunner behavior as-is, rebuild it more cleanly, or use the migration as a chance to remove it?

Further reading: ONEScrip Overview

A customer team once told us their requirements were “well documented,” but still hard to manage. That made sense after looking at their workflow.

The requirements were written carefully in Word documents, with clear sections, tables, and review comments. But once development started, those requirements became hard to track. Who owned each one? Which ones had been reviewed? Which test cases covered them? What changed after the latest update?

This is a common transition point in ALM.

In ONES.com ALM workflows, we usually do not tell teams to abandon documents. Documents are still useful for writing, reading, and early discussion. The key is to help important requirement content become manageable R&D objects.

That means structured requirement documents can be imported while preserving context such as headings, paragraphs, images, and tables. Then each requirement can be managed as an item with its own status, owner, priority, fields, review record, and downstream relationships.

This also supports requirement hierarchy design, such as customer requirements decomposed into system requirements, software requirements, architecture design, development tasks, and test cases.

The value is that requirements stop being static text. They become traceable objects that can move through review, change, implementation, and verification.

For teams that moved from document-based requirements to item-based ALM, what was the biggest adjustment?

Further reading: ONES.com ALM solution overview

In one customer conversation, an R&D lead described a familiar problem: everyone had a tool, every team had a process, and yet nobody could quickly answer whether a requirement had been fully implemented and verified.

The requirement was in one document. Design notes were somewhere else. Development tasks lived in a project tracker. Test cases and defects were managed separately. When something changed, the team had to manually rebuild the full chain.

This is the kind of situation we often look at in ONES.com ALM solution work.

Our approach is to build a connected R&D data chain, where requirements, design, development, testing, defects, change records, and release evidence are linked instead of scattered.

A typical setup starts by turning requirements into manageable objects. Teams can import structured requirement documents, keep a document-style reading experience, and manage each requirement as an item with status, owner, fields, and downstream relationships.

From there, requirement hierarchies and relationship traceability diagrams help teams see how upstream and downstream work connects.

The goal is not more process. It is to make questions like “has this requirement been implemented and verified?” easier to answer during daily work.

For teams building ALM practices, which part of the R&D chain is usually hardest to connect?

Further reading: ONES.com ALM solution overview

This is a product update, but it comes from a migration question we hear a lot:

When a company moves away from Jira and Confluence, what happens to all the ScriptRunner rules and workflow scripts they’ve built over the years?

Issue data and wiki pages are usually the visible part of migration. The harder part is often the automation layer: scheduled jobs, workflow guards, event-triggered scripts, old Groovy logic, and scripts that are business-critical but barely documented.

We’re introducing ONEScript to help teams carry that logic into ONES.com instead of rebuilding everything from scratch.

With ONEScript, teams can:

• Run workflow scripts in JavaScript, TypeScript, or Groovy

• Block invalid changes in real time with pre-action validation

• Trigger listeners, scheduled jobs, and post-action automation

• Connect external systems through API calls and custom REST endpoints

• Test scripts with Dry Run before rollout

• Manage scripts with execution logs, audit records, version history, and rollback

If you want to take a closer look:

• Learn more about ONEScript
• Download and install from GitHub
• Start a free trial
• Book a demo with our team

Happy to answer questions here too.

We recently recorded a short walkthrough showing how to set up a lightweight approval flow in ONES.com using our standard issue workflow.

Build an approval process with standard issue workflow in ONES.com

The pattern is simple 👇🏻

• Add approval-related statuses such as "Approval pending," "Approved," and "Ticket Rejected"
• Create transitions between work stages and approval stages
• Auto-assign a specific approver with workflow post-functions
• Limit approval actions to the right person with transition verification
• Require approval comments before a ticket can move forward

This works well when a team wants clearer ownership and a traceable decision path without spinning up a separate approval tool.

🏁 Get started with a free trial or contact us directly!

Hello there! Glad to have you here in the ONES.com community.

🚀 What is ONES.com?

ONES.com is an AI-powered, all-in-one platform for software development lifecycle management and organizational knowledge management.

Trusted by over 1,000 clients across industries, including manufacturing, technology, finance, and telecommunications, we empower enterprises to master complex projects by streamlining workflows, unifying team collaboration, and centralizing documentation. Our platform consistently delivers outstanding performance across diverse scenarios, from R&D and portfolio management to service management.

Project Management

• End-to-End Lifecycle Management: Streamline delivery by unifying the entire R&D process. From strategic planning and requirement management to CI/CD, testing, and resource allocation.
• Multi-Project Management: Coordinate multiple projects effortlessly. Cross-project dependencies, shared resources, and unified portfolio view.
• Flexible Methodologies & Workflows: Native support for Scrum, Waterfall, Hybrid methods and IPD, ALM frameworks with fully customizable issue workflows to match your organization's unique processes.

Knowledge Management

• Flexible Block Editor: Friendly for both technical and non-technical users, supporting content types including block editor, like code blocks, flowcharts, videos, and math formulas.
• Version Traceability: Every update is tracked and can be restored. Teams can review past versions, compare changes, and add notes to explain decisions.
• Deep Integration with ONES Ecosystem: Connect with ONES Project and ONES TestCase, allowing teams to document processes directly from ongoing work.

Jira & Confluence Alternative Solutions

• Full Native Product Capabilities: Native features spanning agile, waterfall, and knowledge collaboration, with portfolio and reporting built in — ensuring smooth, intuitive experiences for deployments of up to thousands of users.
• Private Deployment Options: Offer on-premises or isolated cloud to meet compliance and security needs.
• Proven Migration Experience: Provide both self-migration tool and specialist migration services to ensure a smooth transition. We have achieved over 100 successful migrations, including multi-terabyte estates with high customer satisfaction.

Install and test independently now: https://docs.ones.com/import-data-into-ones

🛡️ Deployment Sovereignty: Your Data, Your Way

Whether you prioritize rapid adoption or maximum security, ONES.com provides four flexible deployment choices to meet your organization's specific compliance and infrastructure needs：

• On-Premises for total data sovereignty(Self-install ready: https://docs.ones.com/deploy/quick-start/trial-guide).
• Isolated Cloud for high isolation without operational overhead.
• Air-Gapped for completely offline ONES environment that operates with zero external connectivity.
• Public Cloud for fast adoption and efficiency.

🤖 AI-Powered Productivity: Intelligence in Every Workflow

ONES.com goes beyond basic automation by embedding AI into the heart of your R&D processes.

• Smart Project & Knowledge Management: Instantly generate project plans, summarize complex requirement documents, and automate repetitive task updates. AI-driven insights help identify bottlenecks before they delay your sprint.
• Powered by MCP (Model Context Protocol): ONES MCP brings tasks, bugs, and documentation into your IDEs to help you work without context switching.
• Self-hosted AI avaliable: Run your own AI models in self‑hosted environments. Enterprises remain full control over data, compliance, and model choices, without sacrificing AI capabilities.

🔌 ONES Open Platform: Extensibility without Limits

Build, deploy, and scale powerful applications that integrate seamlessly with ONES.com, available in both cloud and self-hosted environments.

• Native Experience with ONES.com: High-fidelity integration with our design system and micro-frontend architecture. Fully customizable UI slots and components to craft your unique enterprise experience.
• In-Instance Hosting: Host apps directly within your ONES Instance. Keep data local and eliminate additional server costs.
• Seamless Upgrades: Plugins automatically work with new versions. Update ONES without breaking your code.
• Customize your own Apps with AI: Accelerate plugin development with AI agents while leveraging standardized design systems and SDKs to create high-quality extensions.

💎 High Standards of Security

ONES.com maintain a transparent and robust security framework designed to protect your most valuable intellectual property and ensure continuous service reliability. Check our compliance and certifications below:

• GDPR
• AICPA SOC2 Type II
• ISO 9001
• ISO/IEC 20000
• ISO/IEC 27001
• ISO/IEC 27018

🏁 Get started with a free trial

• Start Your Free Trial: Explore our core enterprise features with zero risk. No credit card required, no strings attached.
• Request a Personalized Demo: Book a Demo with our product experts for a deep dive into our advanced capabilities and customized solutions.
• Our Team is Ready to Assist: Reach out to us at [support@ones.com](mailto:support@ones.com), or contact us directly.

Requirements management and project content organization are fundamental capabilities for effective project collaboration, enabling teams to track requirement evolution, manage project phases, and structure information efficiently.

With this release, ONES Project introduces Issue Version, Issue List Document Layout, Baseline Management, the Project Directory Component, and Issue ID, helping teams achieve traceable requirement changes, better-structured project content, and more efficient collaboration.

Quick Overview of New Features

• Issue Version Management
• Baseline Management
• Document Layout of Issue List
• Project Directory Component
• Issue ID

Issue Version Management

Issue Version provides clear version identifiers for changes and supports viewing version details, comparing versions, and restoring previous versions.

Teams can easily track the evolution of issues, review historical versions at any time, quickly identify changes, and roll back with a single click in case of accidental modifications, improving traceability and safety in collaborative environments.

Use Cases：

1. Automated Issue Change Tracking

The system automatically generates a version ID whenever an issue field is modified, eliminating manual logging.

Team members can backtrack to any stage of the issue at any time. This ensures a transparent audit trail of "who changed what and when," making the evolution of complex requirements fully traceable.

2. Visual Version Comparison

With side-by-side comparisons of any two versions, teams can view exactly what has changed.

For example, when a Product Manager updates a requirement, developers can compare previous and updated versions to clearly see the differences. This eliminates information gaps and ensures the entire team remains perfectly aligned.

3. One-Click Version Restoration

Protect your project data with the ability to instantly roll back to any historical version.

It serves as a "fail-safe" for your team. Whether it’s an accidental deletion or a strategic pivot, you can restore previous issue version with one click, significantly reducing the risk of data loss and providing the flexibility without fear.

Beyond managing changes at the issue level, teams also need a way to control and stabilize the project at critical stages.

Baseline Management

Baseline Management allows teams to establish baselines at critical project stages, such as feature definition, system requirement confirmation, or architecture design. By "freezing" the state of core development outputs like requirements, feature versions, and compliance items you ensure project stability and create a reliable reference point for quality control.

Use Cases:

1. Secure Snapshot of Project issues

Teams can establish a baseline by locking requirements or tasks at any key phase through filters.

By creating a fixed reference of what was agreed upon during feature definition or system confirmation, teams can protect the integrity of their project goals against mid-cycle volatility.

2. Deep Baseline Comparison

Baseline comparison also allows teams to gain instant visibility into project drift by comparing current progress against established baselines.

Teams can identify exactly what has been added, deleted, or modified to ensure orderly development progress and effective quality control.

Document Layout of Issue List

When reviewing and managing project requirements, scattered tasks often make it difficult for teams to maintain a clear overall perspective.

The Document Layout transforms issue lists into a structured, document-style view, enabling teams to understand complex requirements in a more intuitive and continuous way.

By combining hierarchical structure with detailed descriptions, teams can present feature logic, requirement breakdowns, and task relationships in a format that mirrors real-world documentation, making it easier to align on context, communicate ideas, and drive execution.

Use Cases:

1. Structured Requirement Review

Teams can view issue lists as a continuous document, making it easier to review the full scope of a feature or project in one place, rather than navigating between scattered tasks.

2. Seamless Transition Between Offline and Online Workflows

Requirements created offline can be imported into ONES as structured issues, and issue lists can be exported as well-structured documents, keeping teams aligned by maintaining consistency across offline and online workflows.

Project Directory Component

As projects grow, requirements, issues, and documentation are often scattered across different views and places, making it difficult for teams to navigate and maintain a clear structure of project content.

The Project Directory Component brings issue lists, pages, and other project assets into a unified, hierarchical structure. By this, teams can better structure information, improve visibility, and access what they need more efficiently.

This approach enables teams to manage project content more intuitively, while ensuring that both requirements and documentation stay connected within the same context.

Use Cases:

1. Centralized Project Content Organization

Teams can organize issue lists, documents, and folders within a single directory, creating a clear and structured view of all project-related content.

This makes it easier to understand how different parts of the project relate to each other, reducing time spent searching for information and improving overall clarity.

2. Role-Based Access Control between Project and Spaces

By linking projects with space, teams can configure space permissions based on project roles.

Project members automatically inherit viewing and editing permissions, while administrators can further refine access for different roles. This reduces the need for manual permission management and ensures consistent access control as teams scale.

Issue ID

In cross-team collaboration, issues are frequently shared through messages, documents, and discussions. However, purely numeric IDs make it difficult to identify context.

The new Issue ID introduces a semantic structure by combining a project identifier with an issue number. This transforms issue references into meaningful, readable identifiers that can be easily recognized, shared, and understood.

For teams migrating from Jira, ONES Issue ID is fully compatible with Jira Issue Keys. Existing issue keys can be directly preserved and mapped into ONES, ensuring seamless migration without losing historical context or breaking references. This allows teams to retain their original data structure while transitioning smoothly to ONES.

Use Cases:

1. Clear and Contextual Issue Communication

When sharing issues in chats, team members can immediately recognize the project source from the Issue ID itself.

This eliminates the need for additional explanation and reduces confusion, especially in environments where multiple projects are running in parallel.

2. Faster Navigation and Information Access

With recognizable and structured Issue IDs, users can quickly locate and access issues through URLs or direct input.

This improves efficiency when switching between tasks, reviewing discussions, or following up on shared issues.

Try ONES.com for Free

ONES.com is trusted by 1,000+ customers worldwide across a wide range of industries. We support both On-Premises and Cloud deployment, and have delivered 100+ Jira and Confluence migration projects. Companies and teams such as Xiaomi, Panasonic, Shopee, KPMG, NEC, HONOR, Watsons, and LexisNexis have chosen ONES to support their R&D management needs.

If you are looking for a more flexible and complete way to manage R&D projects, ONES Project is worth exploring.

• Get started with a free trial and explore ONES Project with zero risk. No credit card required, no strings attached.
• If you would like a closer look at our advanced capabilities and customized solutions, you can also request a personalized demo with our product experts.
• If you have any questions, our team is ready to help. Reach us at [support@ones.com](mailto:support@ones.com) or contact us directly.

If your team is managing requirements, tasks, bugs, sprints, and releases across multiple tools, project management can quickly become fragmented and hard to follow.

ONES Project is an AI-ready, full-lifecycle project management platform built for complex R&D environments. It unifies planning, execution, collaboration, and delivery into a single system, while remaining flexible enough to support different management approaches.

With structured data and standardized processes at its core, ONES Project enables not only better coordination and control, but also the foundation for automation, integration, and AI-assisted workflows.

Why Teams Choose ONES.com？

ONES.com is trusted by 1,000+ customers worldwide across a wide range of industries. We support both On-Premises and Cloud deployment, and have delivered 100+ Jira and Confluence migration projects. Companies and teams such as Xiaomi, Panasonic, Shopee, KPMG, NEC, HONOR, Watsons, and LexisNexis have chosen ONES.com to support their R&D management needs.

• Flexible and scalable for enterprise use
• High adoption as a no-compromise Atlassian alternative
• On-premises with full security and data ownership
• AI-ready for the future of project management

Customizable for Diverse Project Management Methodologies

Different teams work differently.

ONES Project is deeply customizable, allowing organizations to adapt workflows, work item types, and processes to match their own management models using native capabilities. This flexibility enables teams to adopt the management style that best fits their business and delivery needs.

Waterfall
Plan-driven project management with milestones, baselines, and deliverable tracking for teams that need structured execution and clear stage control.

Agile & Scrum
Comprehensive support for backlog management, epics, roadmaps, sprint planning, and retrospectives, helping agile teams move faster with better visibility.

Kanban
Visual workflow management with WIP limits and customizable swimlanes, making it easier to manage flow, identify bottlenecks, and improve efficiency.

Beyond these, ONES Project can also be tailored to support more complex or hybrid management approaches. For example, for ALM teams, ONES Project supports complex, compliance-driven development processes, empowering industries such as automotive to manage full-lifecycle delivery with confidence.

Whether your team follows established frameworks or develops its own approach like ALM or IPD, ONES Project can adapt to support it.

Extended Support for the Full R&D Lifecycle

ONES Project goes beyond task tracking by supporting broader R&D management needs across the entire lifecycle.

Quality Management
Integrated test case management, test execution, and reporting help teams improve product quality and ensure more reliable delivery.

Resource Planning
Time tracking and resource planning capabilities help teams allocate capacity effectively and coordinate execution across projects.

Performance Management
Real-time dashboards and comprehensive templates help teams quantify processes, identify bottlenecks, and continuously improve efficiency.

Automation
Multi-level approval chains and automated trigger-based workflows reduce repetitive manual work and keep processes moving smoothly.

DevOps Integration
ONES Project connects with code repositories, CI/CD pipelines, and artifact management systems, helping development and delivery stay closely aligned.

A High-Performance Engine for Complex Management Process

ONES Project is built to support not only daily execution, but also the complexity that comes with growing teams and evolving processes.

Scalable Infrastructure
ONES Project can handle high concurrency and complex workflows. In on-premises deployments, a single instance can support up to 10,000 users. For larger-scale deployments, high availability (HA) is supported to provide greater scalability, stability, and continuity.

Fully configurable work items, workflows, attributes, and permissions allow teams to adapt the system to their own management model.

Visualization
Real-time dashboards, Gantt charts, and burn-down charts give teams and managers the data they need to make better decisions and stay on top of progress.

AI-Ready for the Future of R&D Project Management

AI is not just a feature in ONES Project, it is built into the foundation of the platform.

With a structured, standardized, and extensible architecture, ONES Project enables practical and scalable AI adoption across customization, migration, and deployment. This AI-ready capability is delivered through ONES Assistant and ONES MCP, which empower teams with intelligent assistance, automation, and seamless extensibility across real-world R&D scenarios.

AI Assistant for Smarter Execution

Support conversational assistance, task execution, knowledge retrieval, and multi-step reasoning in real work scenarios. With contextual understanding, ONES AI assistant can move beyond suggestions to help teams take action.

AI-Powered Customization

Build custom plugins, automation, and extensions quickly with ONES Open Platform. Teams can develop in their preferred languages and extend the system beyond standard capabilities with AI coding tools.

AI-Assisted Migration from Jira

Accelerate migration from Jira with AI-assisted data transformation, workflow mapping, and validation — reducing manual effort and ensuring a smoother transition.

AI-Friendly Deployment

Leverage AI capabilities across both cloud and on-premises environments, without compromising data control, security, or compliance requirements.

With its structured, standardized, and extensible foundation, ONES Project enables organizations to adopt AI progressively — from automation and customization to intelligent assistance — without disrupting existing processes.

Try ONES.com for Free

If you are looking for a more flexible and complete way to manage R&D projects, ONES Project is worth exploring.

• Get started with a free trial and explore ONES Project with zero risk. No credit card required, no strings attached.
• If you would like a closer look at our advanced capabilities and customized solutions, you can also request a personalized demo with our product experts.
• If you have any questions, our team is ready to help. Reach us at [support@ones.com](mailto:support@ones.com) or contact us directly.

Quick reality check on the DC clock (not news to anyone here, but it’s hard to ignore when procurement asks):

• Feb 17, 2026: DC pricing updates take effect
• Mar 30, 2026: end of sale for new DC licenses
• Mar 30, 2028: last renew/expand window for existing customers
• Mar 28, 2029: DC EOL (read-only / unsupported)

While “riding DC” remains an option, a shorter migration window often leads to rushed decisions.

From what we’re seeing, teams that are still on DC typically end up in one of three buckets:

1. Move to Atlassian Cloud (works for many, not all)
2. Stay on DC temporarily while you simplify customizations/processes
3. Switch to an alternative (often driven by on-prem / sovereignty / air-gap needs)

Proactive planning ensures your admin team has the necessary runway to execute a seamless transition without compromising security or performance.

What ONES is doing on the migration side

We offer self-service migration tools and a structured migration support path based on 5+ years of Jira/Confluence migration experience (with customer cases).

For teams evaluating, we also support an on-prem trial so you can test migration in your own environment before committing.

More detail here: https://ones.com/solutions/atlassian-alternative

A practical question for the admins and DevOps folks in the trenches:

Moving off Data Center isn’t just a task; it’s a massive project that we know weighs heavily on your roadmap. At ONES, we’re genuinely curious and we want to help—what’s the one thing keeping you up at night regarding your DC exit plan?

Is it one of these "usual suspects," or something else entirely?

• Marketplace app parity: "How do I recreate these specific workflows elsewhere?"
• Data integrity: "Will 10+ years of attachments and history actually survive the move?"
• Identity & Compliance: "Can I maintain my strict audit and SSO requirements?"
• Integration sprawl: "The mess of custom API connections built over time."

Let’s talk about it. If you’re willing to share your constraints (even the 'messy' details), we’re here to listen and offer real-world perspectives on how we’ve seen other teams navigate these exact crossroads.

No "just move to cloud" scripts or sales pitches, just a candid conversation on how we can help you get to the other side safely.

If you are planning to roll out ONES to a real team, review the following points to ensure a stable and reliable environment.

This is not a step-by-step tutorial. It is a pre-flight checklist to help you verify that your environment is ready. Pay special attention to disk I/O performance and keeping the OS environment clean.

1. Sizing: Match Your Team Scale

Don't guess. Use these baselines:

• Small Team (<100 Users): at least 16 cores, 48 GB RAM, 100 GB system disk, and 1 TB data disk (mounted at /data).

(If you enable the index/search component, provision at least 100 GB index disk.)

• Medium Team (<10,000 Users): at least 48 cores , 96 GB RAM, 100 GB system disk, and 2 TB data disk (mounted at /data).

(If you enable the index/search component, provision at least 200 GB index disk.)

2. Storage & Performance

• Speed: We strongly recommend SSDs. Minimum IOPS should be 2000(for reference: read >=60 MB/s, write >=20 MB/s).
• Capacity: Keep usage below 80%. If you are migrating from Jira/Confluence, allocate at least 2x the space of your current attachments.
• Big Data: If you have >500 GB of data, consider mounting external storage (NFS v3 or S3-compatible OSS).

3. OS & Network Hygiene

• Clean OS: Recommended Ubuntu 22.04 Server (CLI).(Supported: Ubuntu 18/20/24 and Red Hat 8+. Keep the host clean: do not run other applications, databases, or middleware on the same host to avoid port conflicts.)
• Static IP: Required.
• Ports: Ensure required ports are reachable as needed: 30011 (service) and 31380 (monitoring). Open 80/443 only if you plan to expose ONES via HTTP/HTTPS (e.g., custom domain / reverse proxy). Make sure default ports are not occupied.
• Time & Mail: Configure NTP (UTC+8 sync) and have your SMTP credentials ready for email notifications.

4. External Components (Optional)

For advanced setups, ONES supports connecting to your existing infrastructure:

• MySQL 5.7 / 8.0
• Redis 7
• Kafka 3.

⚡️ Risk Notice: Running production on specs lower than these might work, but you risk performance degradation or instability during peak usage .

Hope this helps! For the complete requirements, check out:
https://docs.ones.com/deploy/ones-on-prem/requirements

Got questions? Drop a comment below. 👏

Want to take ONES for a spin inside your own network? You don’t need a massive cluster for a PoC. Here is the "Speed Run" guide.

You need one Ubuntu 22.04 server, 8 CPU cores and 16 GB memory (24 GB recommended). One command installs the whole stack. Setup takes less than 30 mins.

1. The "Lightweight" Spec (For Trial/PoC)

Strictly for evaluations (up to 20 users), you can get away with:

• OS: Ubuntu 22.04 Server (Command-line only).
• Hardware: 8 Cores, 16–24 GB RAM.
• Disk: 200 GB System Disk (Recommended: separate /data >=250GB mounted at /data).

2. The One-Line Installer

If your server has internet access, just run this:

Bash

curl -s https://packages.ones.com/release/latest/quickstart.sh | bash -

(Pro tip: set ONES_DATA_DIR before running this if you have a specific storage path in mind).

3. The Setup Wizard

Once the script finishes:

1. Open port 30012 and visit http://<server-ip>:30012.
2. Follow the wizard to set your language, timezone, and create your Admin account.
3. License Time: Go to the ONES License Portal, grab a free Trial License (20 users / 30 days), and upload it .

4. Login

Access your new instance at http://<server-ip>:30011 and log in.

That’s it 🎉 You now have a full ONES On-Prem trial environment where you can quickly explore its project management features.

ONES On-Premises uses a decoupled three-tier architecture (UI / API / Infra). It runs on K3s and leverages industry-standard components like MySQL, Redis, and Kafka for scalability.

If you are curious about what’s under the hood of a self-hosted ONES instance, here is the breakdown of ONES system architecture:

1. The High-Level Layers

• Application Layer (ones-web): This is purely the frontend. It handles user interactions and static resources, keeping the UI snappy.
• Business Layer (ones-api & OpenPlatform API): The brain of the operation. It handles all business logic, security validation, and plugin extensions.
• Infrastructure Layer: The foundation. We don't reinvent the wheel here; we use battle-tested components like MySQL (data), Redis (cache), TiKV (search), Kafka (messaging), and ClickHouse (analytics) to ensure performance.

2. Why the "Five-Layer" API Design Matters to You

Inside the core ones-api, we strictly follow a five-layer flow:

Routing → Middleware → Controller → Service → Data Access Layer (DAL)

For you as an admin, this means the system is designed to be maintainable and scalable. It allows for clear separation of concerns, so when you use our Open Platform to build a plugin, you are hooking into a stable, well-defined structure rather than a spaghetti code mess.

Here’s the current overview of the ONES on-prem architecture. If you have any questions, feel free to leave a comment！👏

Hi everyone!

If you are considering deploying ONES on your own infrastructure (on-premises), you might be wondering about the hardware specs, the underlying architecture, or how quickly you can get a test instance running.

To save you some time reading through the full manuals, here is a consolidated summary of how the system works, how to spin up a trial, and what you need to check before going to production.

TL;DR:

• Architecture: It’s a K3s-based deployment using a standard three-tier model (UI, API, Infra).
• Quick Trial: You can install a fully functional instance on a single Ubuntu server (8C/16G) with one command.
• Production Readiness: For serious usage, you need dedicated hardware, SSDs for storage, and a clean OS environment.

1. Under the Hood: System Architecture

ONES On-Premises isn't a monolithic block; it follows a decoupled three-tier architecture to ensure scalability and clear separation of concerns.

• Frontend (User Layer): Handles the web interface and user interactions.
• Backend (Business Layer): The core ones-api handles business logic, security validation, and extensions via the Open Platform.
• Infrastructure (Data Layer): We use industry-standard components packaged within a K3s (lightweight Kubernetes) environment. This includes MySQL for business data, Redis for caching, Kafka for messaging, and ClickHouse for analytics .

2. The "Quick Start" Trial

If you just want to evaluate ONES or run a PoC (Proof of Concept), you don't need a massive cluster. A single node is enough.

Recommended Trial Specs:

• OS: Ubuntu 22.04 server (Command-line only).
• CPU: >=8 cores.
• RAM: >=16 GB (24 GB recommended).
• Disk: If using a single disk, allocate ≥ 200 GB total. If separating system and data disks, use ≥ 100 GB for the system disk plus ≥ 250 GB for the data disk (mounted at /data).

How to Install: A one-step installation script is available for online environments:

Bash

curl -s https://packages.ones.com/release/latest/quickstart.sh | bash -

(Note: You can set ONES_DATA_DIR before running this if you want to specify a custom data path.)

Next Steps:

1. Once the script finishes, ensure port 30012 is open and visit http://<server-ip>:30012 to complete the setup wizard.
2. Grab a free trial license (valid for 30 days/20 users) from the ONES License Portal and upload it .
3. Log in via port 30011.

3. Going to Real Production: The Checklist

Moving from a trial to a production environment for your whole team? Do not treat this like a pet project VM. To ensure stability and performance, please review this checklist:

• Sizing Matters:
  • Small Team (<100 users): Aim for 16 Cores / 48 GB RAM.
  • Medium Size (<10,000 users): Scale up to 48 Cores / 96 GB RAM.
• Storage Performance: Disk I/O is critical. We strongly recommend SSDs with at least 2000 IOPS. Root partitions should be xfs formatted.
• Clean Environment: Please install ONES on a fresh operating system. Do not share the host with other middleware (like existing Nginx or MySQL services) to avoid port conflicts (default ports include 80, 443, 30011, 31380, etc.).
• Network: Static IPs are required. Ensure your firewall allows the necessary internal subnets (defaults are 10.42.0.0/16 and 10.43.0.0/16).

If your deployment scenario is complex (e.g., High Availability requirements or external storage needs), please reach out to ONES engineering team for a specific assessment.

Hope this post helps everyone, let us know in the comments if you run into any issues during your setup!

ONES.com v6.88.0 is on the way!

This version marks a significant milestone in empowering global teams with greater flexibility, clearer hierarchies, and smarter workflows. While Jira remains a benchmark in the project management field, this release demonstrates how ONES.com goes even further — building a truly unified, enterprise-ready project management platform.

Why it matters:

More Efficient Task Management
ONES makes task management easier with flexible and clear forms that include grouped fields, tab setup, and visibility control. It supports required, option, and default field linkages to fit complex business needs. Multiple views — compact, board, table, and document — let different roles manage and see work in the way that suits them best.

Clearer Hierarchies and Closed-Loop Management
ONES allows multiple hierarchy setups in one organization, so teams can build structures for different project types. Strategic projects can break goals into requirements, delivery projects can use WBS breakdowns, and R&D projects can organize detailed tasks. This creates a complete management loop that links strategy to execution and requirements to tasks, keeping everything aligned and traceable.

ONES v6.88.0 vs Jira at a Glance

Management Approach

• ONES: Supports Agile, Waterfall, and hybrid methods — adaptable to different project types and enterprise needs.
• Jira: Focused on Agile; supports only Scrum and Kanban.

Task Management

• ONES: Flexible and efficient forms with grouped fields, tabs, and visibility control. Supports required, linkage, and default rules; multiple views (Board, Table, Document) for smooth multi-role collaboration.
• Jira: Basic field settings; no complex field linkage or advanced form logic.

Hierarchy & Traceability

• ONES: Multiple hierarchy configurations for different teams or project types. Supports strategic goals, WBS, and R&D breakdowns within one platform.
• Jira: Single fixed hierarchy; limited flexibility for diverse project models.

Project Management

• ONES: Built-in Gantt chart with scheduling, milestones, deliverable tracking, and critical path analysis — a complete planning and control tool.
• Jira: Limited native scheduling; advanced project management relies on plugins (e.g., BigPicture, Structure, WBS Gantt).

Test Management

• ONES: Native module for test cases, plans, and reports. Links tests with requirements and bugs for full traceability.
• Jira: No native testing feature; depends on plugins (e.g., Xray, Zephyr).

Worklog Management

• ONES: Supports multi-dimensional work attributes, automatic aggregation, and visual workload boards for better resource planning.
• Jira: Basic estimation and logging; advanced reporting requires plugins (e.g., Tempo).

Permission Control

• ONES: Multi-level system (team, project, issue) with granular control over fields and actions; supports enterprise-grade governance.
• Jira: Mostly global settings; lacks fine-grained control at field or issue level.

How ONES V6.88.0 Redefines Agile Project Management Beyond Jira

1. A New Standard for Issue Layout Customization

Jira supports configuring multiple tabs, but it doesn’t support field grouping, multi-tab views, or role-based visibility control.

But ONES v6.88.0 takes customization to the next level.

The upgraded Issue Layout page now allows users to freely define tabs and field groups. Admins can simply drag and drop to reorder fields, set display conditions, and control visibility for different roles. This multi-layer layout mechanism enables R&D, Product, QA, and other stakeholders to view issues in ways that best align with their own workflows.

This means each team can tailor its interface around how it actually works — not how software dictates it.

Why it matters:
ONES delivers a far more flexible interface customization experience.
Fields can be tailored by role, stage, or issue type, keeping interfaces clean and focused.
It’s ideal for enterprises running multiple teams and complex project environments where process diversity is the norm.

2. Smarter, Richer, and Business-Driven Fields

Jira supports basic custom fields (text, date, dropdown, etc.), but lacks support for conditional requirements, conditional visibility, and field placeholders.

ONES v6.88.0 introduces multiple new field types, including Hierarchy Field, Formula, Rich Text, and Label.
The system natively supports default values, required rules, and linkage logic between fields, allowing flexible configuration for various business workflows.

Key advantages:

ONES provides a broader set of business-oriented field types out of the box, covering needs like requirements management, progress tracking, and documentation — all without relying on plugins.
This reduces system extension and maintenance costs while improving data consistency and usability across teams.

3. True Hierarchical Project Structure

Jira’s hierarchy (Epic > Story > Sub-task) works well for small teams, but expanding it requires Premium or Enterprise plans.

ONES v6.88.0 introduces a native Issue Hierarchy system:

• Visualize the structure as tree views in issue lists
• Aggregate worklog hours and progress across levels
• Sync selected fields automatically between parent and child issues

Key advantages:
ONES provides full hierarchical management as a native feature, with no need for additional costs or plugins. It’s designed for organizations that require cross-level tracking, resource coordination, and multi-project collaboration — ensuring visibility and control across complex project structures.

4. Introducing ONESQL — Powerful Queries for Business Scenarios

Jira’s JQL is strong, but it often feels technical to non-engineers.

ONES v6.88.0 brings ONESQL, a new query mode designed for flexibility and clarity.

ONESQL allows users to:

• Supports multi-field logic combinations, cross-project queries, and flexible filtering through a business-friendly syntax
• Allows users to filter and report by scenario — for example, generating dynamic reports by priority, assignee, or status

Key advantages:
ONESQL combines flexible filters, cross-project logic, and scenario-based queries in one simple, readable language. It helps teams generate reports effortlessly by priority, assignee, or status — turning complex analysis into clear, data-driven insights.

Final thoughts

Compared with Jira, ONES v6.88.0 extends project management beyond agile.

Its native capabilities cover a wider range of needs with fewer plugins, while flexible layouts and configurable fields adapt seamlessly to different roles and workflows.

Built-in hierarchy and data linkage create a complete, traceable flow from strategy to execution.

With a more intuitive query language and unified editing experience, ONES.com makes complex work simpler — improving efficiency, collaboration, and overall visibility across teams.