[FEATURE REQUEST] Sharing NG: Permalink

Permalinks (oCIS) should be always reachable. As the app is built, that option is set inside of the Share menu (or Members in case of the space management).

That means, sharing option should be always displayed, and then, inside of it, the permalink. Other options/capabilities will rule whether the "sharing with users" or "sharing by link" will be available.

Current condition in FilterFileMenuOptionsUseCase.kt

if (!onlyAvailableOfflineFiles && shareViaLinkOrWithUsersAllowed && resharingAllowed &&
            hasResharePermission) {

!onlyAvailableOfflineFiles -> make it unavailable in the av. offline shortcut
shareViaLinkOrWithUsersAllowed -> checks in setup.xml whether share_via_link_feature or share_with_users_feature are true
resharingAllowed -> it's true if the item is not "shared with me" (so, it's an item of my list) or the resharing capability is true
hasResharePermission -> it's true if there is only one item selected (no multiselection) and the item itself has the resharing (R in the oc:permissions from the PROPFIND response)

That condition was built for oC10, but oCIS has a different background. Basically, oCIS does not allow resharing (capability always comes with a false) and those items in custom spaces with no sharing permissions, come from server with empty oc:permissions.

TO DO's:

Find the way to make reachable the permalink/private link in all cases:
- oCIS: Show the Share item regardless the R permission. That permission is used to show the options in the Share view. TODO: check if there is any other permission available in the Graph API for that aim)
- Add permalink on the rigth side, just in the same layout as the header

TASKS

Problem

On oCIS, the permalink can become unreachable. The only entry point to the permalink is the Share screen, which is opened only when FileMenuOption.SHARE passes the gate in FilterFileMenuOptionsUseCase.kt:

if (!onlyAvailableOfflineFiles && shareViaLinkOrWithUsersAllowed && resharingAllowed &&
            hasResharePermission) {

That condition was designed for oC10. On oCIS it hides the Share option — and with it the permalink — in valid cases:

oCIS (personal space): the resharing capability always comes as false, so resharingAllowed gates Share away even for items the user owns in their own personal space, and the permalink becomes unreachable.
oCIS (custom spaces): the resharing capability always comes as false, and items in custom spaces with no sharing permissions arrive from the server with empty oc:permissions (so hasResharePermission, the R flag, is false). The Share option is therefore hidden and the permalink is lost.

The four conditions, as they stand:

!onlyAvailableOfflineFiles → keep it unavailable in the available-offline shortcut.
shareViaLinkOrWithUsersAllowed → share_via_link_feature or share_with_users_feature is true in setup.xml.
resharingAllowed → true if the item is not "shared with me", or the resharing capability is true.
hasResharePermission → true only when a single item is selected and it carries the R permission in oc:permissions.

The permalink UI itself is also not implemented on oCIS. There are two different Share screens:

oC10 uses OcsShareFileFragment + share_file_layout.xml. The permalink is already implemented and working here (getPrivateLinkButton, controlled by showOrHidePrivateLink(), wired to listener.copyOrSendPrivateLink(file)). This is out of scope and must not change.
oCIS uses GraphShareFragment inside ShareActivity with the members_activity.xml header. That header already contains a permanent_link_button (right side, copy-link icon), but it is not functional: ShareActivity.setupFileHeader() hard-codes binding.permanentLinkButton.isVisible = false and never sets a click listener. So on oCIS the permalink button is permanently hidden and does nothing.

There is a working reference pattern for the exact same button in SpaceMembersActivity.kt, which does permanentLinkButton.setOnClickListener { copyOrSendLink(...) }. ShareActivity already implements the copyOrSendPrivateLink(file) override (fileOperationsHelper.copyOrSendPrivateLink(file)), so the plumbing to copy/send the link already exists.

Desired behavior

On oCIS, the Share menu option is always reachable for a single selected item (both personal and custom spaces), regardless of the resharing/sharing capability values, the R permission, or the share_via_link_feature/share_with_users_feature setup flags. The individual sections inside the Share screen ("share with users" / "share by link") continue to be ruled by their own capabilities and feature flags; only the reachability of the screen (and therefore the permalink) becomes unconditional on oCIS.
On oCIS, the permalink is actually shown and functional in the Share header: the permanent_link_button in members_activity.xml must be made visible when a private link exists and wired to copy/send that link, mirroring the SpaceMembersActivity reference. It must be hidden when the item has no private link or the filesPrivateLinks capability is FALSE.
oC10 behavior is unchanged. The Share gating condition and the already-working private-link button in OcsShareFileFragment stay exactly as they are today.

User stories

As an oCIS user, I want to open Share for an item in my personal space, so I can still copy its permalink even though the resharing capability is false.
As an oCIS user, I want to open Share for an item in a custom space with no sharing permissions, so I can still copy its permalink.
As an oCIS user, I want the permalink button in the Share header to actually appear and copy/send my permalink, because today it is hidden and non-functional.
As an oC10 user, I want nothing about Share or the private link to change.

Constraints

The change MUST affect only oCIS accounts (accounts where the spaces capability is enabled, i.e. isSpacesAllowed()). The oC10 code path MUST be left byte-for-byte equivalent in behavior.
On oCIS, the Share option MUST remain hidden in the available-offline shortcut (onlyAvailableOfflineFiles).
On oCIS, the Share option MUST remain restricted to single selection (no multiselection).
The capability/feature-flag gating of the "share with users" and "share by link" sections inside the Share screen MUST stay unchanged on both server types.
The oCIS permalink button MUST reuse the existing permanent_link_button in members_activity.xml and the existing copyOrSendPrivateLink(file) plumbing; no new layout position and no new copy/send mechanism.

Acceptance criteria

Out of scope

Any change to oC10: the oC10 Share gate and the oC10 private-link button (OcsShareFileFragment / share_file_layout.xml) are untouched.
Changing the permalink button layout/position (it stays as it is in the oCIS header today).
Changing the capability logic of the "share with users" / "share by link" sections inside the Share screen.
Any Graph API changes to fetch a new file-level share permission (none exists in the codebase today).

Assumptions

oCIS accounts are identified by the spaces capability being enabled (OCCapability.isSpacesAllowed()), the same discriminator already used across the app (MainApp, SpacesListViewModel, AuthenticationViewModel, …). The stored capability is already available inside FilterFileMenuOptionsUseCase via capabilityRepository.
The permalink on oC10 is already implemented and correct inside OcsShareFileFragment (header getPrivateLinkButton, controlled by showOrHidePrivateLink()), so no oC10 work is required.
The permalink on oCIS is not implemented: the permanent_link_button exists in members_activity.xml but ShareActivity.setupFileHeader() forces it hidden and sets no listener. It must be implemented following oC10's show/hide rule (hidden when file.privateLink is null/empty or filesPrivateLinks is FALSE) and the SpaceMembersActivity click wiring, reusing copyOrSendPrivateLink(file).
OCFile.privateLink is populated for oCIS from the oc:privatelink PROPFIND property (RemoteFile maps OCPrivatelink), so no data-layer change is needed.
oCIS delivers per-file permissions through the same oc:permissions PROPFIND property as oC10; there is no separate file-level Graph "sharePermission". The R flag therefore cannot be relied upon for oCIS items, which is why oCIS reachability must not depend on it.
The reachability change is confined to the Share gating branch in FilterFileMenuOptionsUseCase.kt; the permalink change is confined to ShareActivity.setupFileHeader(). No Params, caller, or Koin changes are required, because the oC10 branch keeps using all existing inputs.

Implementation notes

FilterFileMenuOptionsUseCase.kt:90-91 — split the SHARE gate by server type using the already-fetched capability:
```
val isOcis = capability?.isSpacesAllowed() == true
val shareReachable = if (isOcis) {
    !onlyAvailableOfflineFiles && isSingleSelection(files)
} else {
    !onlyAvailableOfflineFiles && shareViaLinkOrWithUsersAllowed &&
        resharingAllowed && hasResharePermission
}
if (shareReachable) {
    optionsToShow.add(FileMenuOption.SHARE)
}
```
Do not remove resharingAllowed, hasResharePermission, anyFileSharedWithMe, the capability lookup, the capabilityRepository dependency, or the shareViaLinkAllowed/shareWithUsersAllowed Params fields — they are all still needed by the oC10 branch. No caller (MainFileListViewModel, FileDetailsViewModel, PreviewVideoViewModel, PreviewAudioViewModel, PreviewTextViewModel, PreviewImageViewModel) and no Koin factory (UseCaseModule) changes are required.
ShareActivity.setupFileHeader() — implement the oCIS permalink: make permanentLinkButton visible when file.privateLink is non-empty and filesPrivateLinks is not FALSE (mirror oC10's showOrHidePrivateLink()), and set permanentLinkButton.setOnClickListener { copyOrSendPrivateLink(file) } (reference: SpaceMembersActivity.kt:74). Replace the hard-coded binding.permanentLinkButton.isVisible = false at ShareActivity.kt:172.
Add a changelog entry under changelog/unreleased/.

Navigation Menu

Repository navigation

[FEATURE REQUEST] Sharing NG: Permalink #4939

TASKS

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE REQUEST] Sharing NG: Permalink #4939

Description

TASKS

Activity

joragua commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions