Feature: change edit and re-share on an existing internal share

[branch1337]

Description

After a recording is shared with a user, the grantor cannot change that user's permissions. The share modal lists the person and shows a green "Edit" pill when can_edit is true, a blue "Reshare" pill when can_reshare is true, and a gray "View" pill when both are false. Those pills are status labels. The only action on the card is the red revoke button. The same list on Shared Transcripts offers revoke for a manual share and nothing else.

The practical workaround is to revoke the share and create it again with the checkboxes set differently. That is not a permission edit. Revoke is a cascade deletion of the share row, and creating the share again is refused while the row still exists. A second share of the same recording to the same user is also impossible because of the unique constraint on that pair.

Affected Version

v0.10.16-alpha

Requested Feature

On a manual internal share, the grantor can change can_edit and can_reshare in place. The recipient, the recording, the share id, and the recipient's inbox and personal notes stay as they are.

In the share modal, each manual share the current user granted gets a control beside the revoke button. Its accessible name is "Change permissions", not "Edit". Activating it shows the same two checkboxes used when adding a user, filled with the flags on that row, and a save action that writes them. The green, blue, and gray pills stay read-only status and keep their current labels.

Shared Transcripts gets the same control on each manual recipient row that already shows Revoke. Rows shared with the current user stay read-only.

Group-tag and group-folder shares do not get the control. Their flags still come from the group rule that created them.

A grantor cannot raise a flag above the permissions they themselves hold. Lowering a flag does not delete shares that recipient already created for other people. Revoke remains the action that cascades.

Proposed Implementation

Add PATCH /api/internal-shares/<int:share_id> in src/api/shares.py, on the same blueprint as revoke_internal_share (src/api/shares.py:590-603). That function is the only mutation of an internal share today, and it only deletes. Leave share_recording_internal (src/api/shares.py:432-476) as the create path, including the 409 already_shared response. Leave update_share (src/api/shares.py:368-381) as the public-link settings update. It writes share_summary and share_notes on the public Share row and is not on this path.

@shares_bp.route('/api/internal-shares/<int:share_id>', methods=['PATCH'])
@login_required
def update_internal_share(share_id):
    """Change can_edit and can_reshare on a manual internal share."""
    if not ENABLE_INTERNAL_SHARING:
        return jsonify(api_error('internal_sharing_disabled')), 403

    share = db.session.get(InternalShare, share_id)
    if not share:
        return jsonify(api_error('share_not_found')), 404
    if share.owner_id != current_user.id:
        return jsonify(api_error('share_revoke_denied')), 403
    if share.source_type != 'manual':
        return jsonify(api_error('share_source_locked')), 409

    data = request.json or {}
    if 'can_edit' not in data and 'can_reshare' not in data:
        return jsonify(api_error('permissions_required')), 400

    new_edit = bool(data['can_edit']) if 'can_edit' in data else bool(share.can_edit)
    new_reshare = bool(data['can_reshare']) if 'can_reshare' in data else bool(share.can_reshare)
    recording = db.session.get(Recording, share.recording_id)
    if not recording:
        return jsonify(api_error('recording_not_found')), 404

    is_valid, error_code = InternalShare.validate_reshare_permissions(
        recording, current_user, {'can_edit': new_edit, 'can_reshare': new_reshare}
    )
    if not is_valid:
        return jsonify(api_error(error_code)), 403

    old = {'can_edit': bool(share.can_edit), 'can_reshare': bool(share.can_reshare)}
    new = {'can_edit': new_edit, 'can_reshare': new_reshare}
    if old != new:
        share.can_edit = new_edit
        share.can_reshare = new_reshare
        ShareAuditLog.log_share_modified(
            share_id=share.id,
            recording_id=share.recording_id,
            actor_id=current_user.id,
            target_user_id=share.shared_with_user_id,
            old_permissions=old,
            new_permissions=new,
            ip_address=request.remote_addr,
        )
        db.session.commit()
    return jsonify({'success': True, 'share': share.to_dict()})

validate_reshare_permissions (src/models/sharing.py:145-173) already refuses a grant the caller does not hold. log_share_modified (src/models/audit.py:80-93) already records old and new flags and has no caller. Add share_source_locked and permissions_required next to already_shared in server.apiError (speakr.git/static/locales/en.json:3129). Add the English strings and the same keys in the other locale files that already translate already_shared.

get_internal_shares (src/api/shares.py:548-587) should add permissions_editable on each real share: true only when source_type == 'manual' and owner_id == current_user.id. The owner sentinel row stays without that flag. The modal in speakr.git/templates/modals/unified-share-modal.html:246-251 renders the new button from that flag, beside revoke, and does not treat the pill at speakr.git/templates/modals/unified-share-modal.html:234-236 as a button. createInternalShare (speakr.git/static/js/modules/composables/sharing.js:616-648) keeps posting the add-user checkboxes. A new updateInternalShare in that composable sends the PATCH and replaces the matching row in recordingInternalShares. The add-user checkboxes at speakr.git/templates/modals/unified-share-modal.html:168-194 stay bound to internalSharePermissions and are not reused as the editor for an existing row, so opening the editor does not change what the next Add will grant.

On Shared Transcripts, get_shares_overview already sets revocable for a manual share the caller granted (src/api/shares.py:336-338). The people list (speakr.git/templates/account.html:4219-4225) shows the change-permissions button on the same p.revocable branch as Revoke. The shared-with-me rows stay as they are.

Document the control in "Managing Your Shares" (speakr.git/docs/user-guide/sharing.md:42-45), and say there that the green Edit pill is the current permission, while "Change permissions" writes the flags. State that group shares are unchanged from that screen.

Tests, in speakr.git/tests/test_shares_authz.py, next to test_revoke_internal_share_owner_succeeds:

• test_update_internal_share_grantor_changes_permissions: the grantor PATCHes can_edit from false to true, gets 200, the row keeps its id, and a ShareAuditLog row with action modified stores the old and new flags.
• test_update_internal_share_unchanged_is_noop: the same flags return 200 and write no audit row.
• test_update_internal_share_third_party_denied and test_update_internal_share_recipient_denied: 403, row unchanged. Mirror test_revoke_internal_share_third_party_denied_and_survives and test_revoke_internal_share_recipient_cannot_revoke.
• test_update_internal_share_requires_login: anonymous PATCH is 302 or 401, same as test_revoke_internal_share_requires_login.
• test_update_internal_share_above_ceiling_denied: a grantor whose own share has can_edit false gets 403 when they set can_edit true, via validate_reshare_permissions.
• test_update_internal_share_group_source_locked: source_type='group_tag' returns 409 and the flags stay at the values apply_tag_shares wrote (speakr.git/src/services/tag_sharing.py:52-59).
• test_share_recording_internal_already_shared_still_409: a second POST for the same user still returns 409.

Run them with python -m pytest tests/test_shares_authz.py -k "update_internal_share or already_shared" from speakr.git.

Expected Behavior

• The grantor of a manual share sets can_edit and can_reshare from the share card or from Shared Transcripts. The response is 200 with success: true and the updated share. The share id does not change. The recipient's SharedRecordingState is not reset to the inbox, which a revoke-and-recreate does at src/api/shares.py:515-517.
• The green "Edit" pill, the blue "Reshare" pill, and the gray "View" pill update to match the saved flags. They remain labels drawn from common.edit, unifiedShareModal.reshare, and unifiedShareModal.view (speakr.git/templates/modals/unified-share-modal.html:234-242).
• A caller who is not share.owner_id receives 403 and share_revoke_denied, the same refusal revoke already returns (src/api/shares.py:601-603). The recording owner cannot change a share that someone else granted.
• A grantor who does not hold can_edit or can_reshare cannot turn that flag on. The response is 403 with reshare_edit_not_permitted or reshare_reshare_not_permitted.
• A group-tag or group-folder share returns 409 and share_source_locked. The modal and Shared Transcripts do not show the control. Revoke of a manual share is unchanged, and a group share stays non-revocable on Shared Transcripts.
• POST /api/recordings/<id>/share-internal for a user who already has a row still returns 409 and already_shared (src/api/shares.py:469-476).
• Sending the flags the row already has returns 200 and does not add an audit row. Sending neither flag returns 400.
• Lowering can_reshare or can_edit does not delete downstream shares. Those rows stay until someone revokes them. The next share that recipient tries to create is still checked against their updated flags.

Root Cause Analysis

Permissions are written only when the share row is inserted. share_recording_internal copies can_edit and can_reshare from the request onto a new InternalShare (src/api/shares.py:478-497) and then refuses any later POST for that recording and user with 409 (src/api/shares.py:469-476). unique_recording_share makes a second row for the same pair invalid (src/models/sharing.py:87-91). The only later route, revoke_internal_share, deletes the row (src/api/shares.py:590-603) and cascades to shares that user granted.

The modal never offers another action. For a non-owner row it renders the status pills and one button, whose click handler is revokeInternalShare (speakr.git/templates/modals/unified-share-modal.html:233-251). The client functions that follow are createInternalShare, which POSTs, and revokeInternalShare, which DELETEs (speakr.git/static/js/modules/composables/sharing.js:616-672). Shared Transcripts repeats that split: it prints the permission text and, for a manual share, a revoke button (speakr.git/templates/account.html:4202-4225).

update_share looks like the missing editor and is not. It updates a public Share the caller owns, and only the summary and notes flags (src/api/shares.py:368-381). The user guide describes the same gap: the share list shows the permission level and the revoke icon, and it does not describe a way to change the level (speakr.git/docs/user-guide/sharing.md:42-45).

Additional Context

The green pill uses the word Edit because t('common.edit') is the label for "this person may edit the recording" (speakr.git/static/locales/en.json:1049, drawn at speakr.git/templates/modals/unified-share-modal.html:234-236). The new control needs its own string, unifiedShareModal.changePermissions, so the two are not the same control.

This request does not change how group shares pick their flags. apply_tag_shares sets can_edit from the membership role and can_reshare to false (speakr.git/src/services/tag_sharing.py:52-59), and share_targets skips anyone who already has a row. Editing those flags from the share card would diverge from the group rule. It also does not walk downstream shares when a flag is lowered. A recipient who already re-shared keeps those grants; cutting that chain is still a revoke. Public links stay on update_share.

[murtaza-nasir]

Thank you for the suggestion. The person who granted a share can now change its edit and re-share permissions in place, with a "Change permissions" button in the share window and on Shared Transcripts. A permission can be granted only within the grantor's own permissions, and shares created by a group tag or a group folder still follow the group. Lowering a permission leaves the shares the recipient has already made in place. This will be included in the next release.

[branch1337]

Thank you for considering and implementing the suggestion! And please let me know if any of my reports or requests are confusing. I don’t want to waste your time. I really appreciate the quick response and all your hard work!