fix(collaboration): match WOPI app extensions without case - #3569
Conversation
The WOPI discovery response lists its extensions in lower case, and OpenInApp looks them up with the extension of the file as it is on disk. So a "report.DOCX" found no app url while a "report.docx" opened, and the web UI reported that it could not contact the application, which reads like the editor is down. The extensions now go into the map in lower case and the lookup folds the case as well, so both ends match whatever the app publishes. The log line and the error also name the extension, because neither said which file type had no app. Fixes opencloud-eu#3449
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
🟢 Coverage 100.00% diff coverage · +0.00% coverage variation
Metric Results Coverage variation ✅ +0.00% coverage variation (-1.00%) Diff coverage ✅ 100.00% diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (f293031) 88741 21470 24.19% Head commit (bbebdf9) 88743 (+2) 21472 (+2) 24.20% (+0.00%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#3569) 5 5 100.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
@aduffeck could you add
Thanks! |
Description
The WOPI discovery response lists its extensions in lower case, and
parseWopiDiscoverystores them as the app published them.OpenInAppthen looks uppath.Ext()of the real file name against those keys, which is an exact match. Soreport.DOCXfinds no app url whilereport.docxopens, and the web UI says it cannot contact the application, which reads like the editor is down.Both ends now fold the case: the parser lowercases the
extbefore it becomes a map key, andGetAppURLForlowercases the extension it is given. Either one alone would leave the other side broken if an app ever published an upper caseext.The log line and the returned error also name the extension. Neither said which file type had no app, which is the second half of the issue.
Behaviour worth knowing: if a discovery response declared the same extension twice in different cases, the last one in document order now wins instead of both being kept. No app does that today, and both entries would point at the same action.
Related Issue
Motivation and Context
Files arrive with whatever case the client gave them. A
.DOCXfrom a Windows share or an old export is a normal thing to find in a space, and there is no reason for it to open differently from a.docx. The generic error made it look like an outage of the office app, so the cause was hard to find.How Has This Been Tested?
go test ./services/collaboration/..., all packages passGetAppURLForwith.DOCXand.DocXagainst stored lower case keys, for both the view and the edit actionext="ODT", which has to come back as.odtgo vet ./services/collaboration/...is cleanTypes of changes
Checklist: