This discussion started when @Rebekka Heilmann _viadee_ shared what appeared to be a significant capability improvement:
Did you know that Rovo Chat and Agents can read existing Jira attachments nowadays?
Initial testing looked promising. PDFs and images appeared to be working, and the use case was compelling: validating customer-uploaded credentials directly from attachments.
Naturally, excitement followed. Then the testing continued.
Short Answer
Yes, Rovo can read some Jira attachments, but support varies depending on:
- How Rovo is being used
- The attachment type
- The product context
- The permissions involved
- The specific Rovo experience being invoked
The result is that attachment support may appear inconsistent even when using the same agent.
What Champions Observed
As testing expanded, several patterns emerged.
PDFs Generally Worked
Multiple Champions reported successful results with PDF attachments. Rovo was able to:
- Read PDF content
- Extract information
- Perform requested analysis
- Complete workflow actions based on attachment contents
This was observed in both chat-based interactions and some work-item scenarios.
Images Were Less Consistent
Rebekka's later testing found that PNG files were not behaving the same way. In some cases:
- PDF attachments worked
- PNG attachments returned access errors
- Logs showed HTTP 403 responses
This suggested the issue was not simply attachment access, but potentially how specific file types were being processed.
Context Matters
One of the most important discoveries was that attachment access can vary depending on where the agent is running. Champions observed different behavior between:
- Rovo Chat
- Studio
- Assigned work-item agents
- Automation-driven execution
A capability available in one context did not always carry over into another.
The JSM Permission Twist
Testing also uncovered an important Jira Service Management nuance.In JSM environments:
Attachments may need to be shared with the customer before Rovo can access them.
When attachments were not customer-visible, some tests resulted in access-denied errors. This aligns with how Jira Service Management permissions work more broadly. If an attachment is not accessible to the user or context executing the request, Rovo cannot access it either.
Why This Happens
At a high level, Rovo does not bypass existing permissions. Attachment access depends on:
- User permissions
- Project permissions
- Customer visibility settings
- Execution context
- Product-specific security controls
Two interactions that look identical to the user may actually be operating under different permission models behind the scenes. That can lead to very different outcomes.
The Release Notes Problem
The discussion eventually shifted toward a familiar challenge. Many Champions weren't sure whether they were seeing:
- A newly released capability
- A phased rollout
- A bug
- A regression
- A permissions issue
As @Paulo Ramalho pointed out, the lack of detailed release notes for evolving AI capabilities often leaves customers discovering changes through experimentation rather than documentation. That makes troubleshooting significantly harder.
Champion Takeaway
The most useful lesson from this thread is simple:
Don't assume attachment support is universally available because it worked a few times.
When testing Rovo attachment capabilities, verify:
- The attachment type
- The execution context
- The permissions involved
- Whether you're using Chat, Studio, Automation, or work-item assignment
The good news is that attachment support appears to be expanding. The challenge is that the behavior is still evolving, which means testing in your own environment remains the most reliable way to validate what works today.
