Share Audit Dashboard - Releases

Fixed

• The auditor's read-only view (issue #16) could not be scrolled on Dashboard, All shares or Security alerts — the page clipped instead of showing a scrollbar, making the lower part of those views unreachable. Lookup & Orphans and Deleted shares were unaffected because their content already fit on screen.
• The Share Audit icon in the top app menu rendered white and was barely visible against a light Nextcloud header.

Added

• Move the files of an orphan share's owner, not just the share. A share whose file sits in a disabled account's own home used to be skipped (The new owner cannot access the file) with a note to run occ files:transfer-ownership by hand. The transfer picker in Orphan shares now asks what to move: only the shares (as before), the shares and the files they point to, or everything the account owns. A file move is the Files app's own ownership transfer, so the shares of what moves follow it, keeping their id and, for a link, the same URL. It runs in a background job and a File moves list under the table shows each one as queued, running, done or failed (with the reason), visible to auditors too. Moving a whole account asks for confirmation first (naming exactly the accounts that will be moved) and every move is written to the audit log. A deleted account has nothing to move (its files went with it), and the conditions are checked again when the job runs: an account that has been re-enabled in the meantime keeps its files. Talk, mail and federated shares go along with their file too, not only link, user and group shares. Only one move into a given account runs at a time, however many background workers Nextcloud has started (the database enforces it); a move that finds the account busy tries again a minute later. That matters because the Files app puts what it moves into a folder named after the second and deletes what it finds at a name that already exists, so two simultaneous moves would erase each other's files of the same name. A move that is running is never given up on because of how long it has been running: a very large folder is indistinguishable from a dead worker by age, and freeing the account while it is still writing to it is the data loss all this prevents. Instead a worker holds a lock that the operating system drops the moment the process ends, however it ends: if the next move finds it free, the worker is provably gone and the move is marked interrupted; if the worker cannot be checked (another machine that does not share the data directory), the move stays put until an administrator marks it as interrupted from the list, which is refused while the worker is alive. When Nextcloud's background jobs have not run for over an hour while a move waits (a server without cron, a broken cron entry), the File moves list says so, with the date of the last run, instead of leaving a move "queued" for ever. Needs the two database migrations that come with 0.8.0.

Security

Follow-up to the 0.7.0 review, which found the fixes above incomplete: - A Talk conversation's token still reached an auditor through the Access lookup (the "who can reach this" search): it listed every conversation with its token, took the token back as the lookup key, and an empty recipient listed every Talk share on the instance with the token in each row. The lookup now identifies a conversation to an auditor by an opaque handle (a keyed hash with the instance's secret) and finds it by its name; a token passed in finds nothing, and an empty recipient lists nothing. An admin still gets the token, since an admin may have it. The same hole was open a substring at a time through All shares' search and its recipient filter, and through sorting by recipient: for an auditor those no longer match or order by a conversation's token either (a conversation is still found by its name). - That lookup also ordered its results, and cut them off at twenty, by the conversations' tokens, which is as good as the token to anyone who can create conversations of their own, since every comparison against a token they know is one bit of one they don't (42 comparisons recover eight characters). For an auditor the conversations are now ordered by what is public about them (how many shares, what they are called), with a keyed hash as the last resort, and the search that finds conversations by name is cut off by their id, not their token. - Redacting a token by showing the conversation's name failed for a conversation with no name: the token was its own fallback name, so it came out in the recipient, its display name and its label, in the list, the CSV, the orphan list and the recycle bin. A conversation nobody named is now shown as Unnamed conversation and no field carries its token; the recycle bin shares the one redaction with the other lists instead of keeping its own copy. - Restoring a public link that had a password no longer creates it open for a moment and puts the password back afterwards: it is created protected by a strong temporary password and the original one is swapped in once it exists. This also lets such a link be restored on an instance that enforces passwords for public links, where creating it without one was refused. - Restoring the same recycle-bin entry twice at the same moment (a double click, or two admins) created a link for each request, and each wrote the same original token onto its link: two, three or more live links on one URL, so that revoking the link the owner knew about left the file reachable through the others. A restore now claims the entry first and is one transaction: only one request creates anything, the others are told the entry is gone, and any failure rolls all of it back: the entry stays in the bin, and there is no half-restored link left to clean up. (Checked by racing four simultaneous restores, ten times over: before, all four answered success, on MariaDB and on PostgreSQL; now exactly one does, on both.) - Restoring a link whose original token had since been taken by another share no longer leaves two links on one URL. The database index on the token is not unique, so the restore relied on a constraint that is not there and quietly succeeded; it now checks first, and keeps the link with a new token (or, if it had a password, refuses and keeps the backup, as before). - A restored link could come back with more access than it had. The recycle bin kept a share's permissions, token and password but not hide download nor its download-permission attribute, so a restored link served downloads it had been set to refuse, on the URL already handed out. Both are now kept and put back before the share exists. Entries kept before this version cannot say what they had: a link or mail share from one of them comes back with downloads hidden, and the result says so. - Two live links could end up on one token. Two requests that had each loaded a share before either deleted it left two entries in the bin, and restoring both at the same moment could put the same token on two shares, so revoking one left the URL working through the other. The bin now keeps one entry per share (duplicates already there are dropped when upgrading, keeping the oldest), and a restore holds the link's token until it has committed. - A queued file move could move a different file. The queue kept a path, and whatever was at that path when the job ran was handed over, even if the selected file had been renamed and something else put in its place. The move now checks that the path still holds the file or folder that was selected, and moves nothing (no longer the file or folder that was selected) if not. - The personal view named folders of the owner a user was never given. For a link a user made on something shared with them, My shares and its alerts showed the owner's full path (/Clients/Merger/BoardOnly/report.pdf). They now show the path as that user sees it, or only the file name.

Fixed

• A file move reported "Done" when the Files app could not hand over the shares. The transfer writes a share it failed to update to an output nobody read here and returns as if all went well. After a move, the shares still naming the old owner while their file is now in the new owner's home are looked up: if there are any, the move is Partly done and lists them, to hand over with Only the shares.
• Access lookup and groups. It lists, and Revoke all removes, the shares made directly to a recipient, and now says so (direct shares). For a user it also lists the groups through which they reach shared files (with how many shares each), which revoking the direct shares leaves in place; a user with no share of their own can now be looked up for that too.
• A bulk revoke in Access lookup could move on to another recipient. Each batch read the selected recipient again, so choosing someone else while it ran sent the next batches for them. The recipient confirmed is used for every batch, and search and Back wait for it to finish. Likewise a bulk purge in Deleted shares sends what was ticked when it was confirmed.
• The warning that a revoke left shares behind vanished as the list reloaded.
• A slow answer to an earlier search, filter or page could replace the one asked for last, leaving a list that did not match the filters shown (and an export that did). Only the latest request's answer is shown now.
• Accepting the reason an alert was critical left it sorted among the critical ones, and in the dashboard widget ahead of alerts still critical.
• Searching for 0 in a share list's text filters matched every share.
• Paths in a Team Folder asked Groupfolders for the folder's name once per share; it is now asked once per folder per request.
• A queued file move and its background job are now written together, so a failure between the two can no longer leave a move that never runs.
• Acting on an expired public link deleted it and reported a failure. Every action on a share (revoke, add a password, set an expiration, accept an alert, even the check of who owns it in the personal view) loaded the share through Nextcloud's validity check, which for an expired share deletes it and then throws "the requested share does not exist anymore". So "Revoke all" on links that had expired came back as a failure although it had removed them (they sat in Deleted shares), the same request repeated said "0 of 10 shares updated" about links that were already gone, and a change to an expired link, or an account that did not own it merely asking, could remove it. Shares are now loaded without that check, so revoking an expired link simply works and a bulk revoke reports every one as done. Revoking a share that is already gone counts as done too. A password or a new expiration on an expired link is refused with a clear message (it can only be revoked) instead of deleting it. The same check also hid links whose owner can no longer create links, which an audit has to be able to revoke.
• The exposure map's Other row now has a View button like the others, and asking All shares for an exposure category the app does not have is refused instead of quietly listing everything.
• The dashboard's Internal vs external donut counted every Talk conversation as internal, and the exposure map's Public "View" button opened only public file links, leaving public conversations out of a list that its own count included. Both now come from the same classification as the exposure score, so a category's number and the list behind it are the same shares.
• A Talk conversation the exposure map could not look up (Talk missing, or its tables not what this expects) was counted as internal, so an instance of public conversations could score zero. It is now counted as Other (what could not be classified, weighed like external), never as safe.

Fixed

• The auditor's read-only view (issue #16) could not be scrolled on Dashboard, All shares or Security alerts — the page clipped instead of showing a scrollbar, making the lower part of those views unreachable. Lookup & Orphans and Deleted shares were unaffected because their content already fit on screen.
• The Share Audit icon in the top app menu rendered white and was barely visible against a light Nextcloud header.

Added

• Move the files of an orphan share's owner, not just the share. A share whose file sits in a disabled account's own home used to be skipped (The new owner cannot access the file) with a note to run occ files:transfer-ownership by hand. The transfer picker in Orphan shares now asks what to move: only the shares (as before), the shares and the files they point to, or everything the account owns. A file move is the Files app's own ownership transfer, so the shares of what moves follow it, keeping their id and, for a link, the same URL. It runs in a background job and a File moves list under the table shows each one as queued, running, done or failed (with the reason), visible to auditors too. Moving a whole account asks for confirmation first (naming exactly the accounts that will be moved) and every move is written to the audit log. A deleted account has nothing to move (its files went with it), and the conditions are checked again when the job runs: an account that has been re-enabled in the meantime keeps its files. Talk, mail and federated shares go along with their file too, not only link, user and group shares. Only one move into a given account runs at a time, however many background workers Nextcloud has started (the database enforces it); a move that finds the account busy tries again a minute later. That matters because the Files app puts what it moves into a folder named after the second and deletes what it finds at a name that already exists, so two simultaneous moves would erase each other's files of the same name. A move that is running is never given up on because of how long it has been running: a very large folder is indistinguishable from a dead worker by age, and freeing the account while it is still writing to it is the data loss all this prevents. Instead a worker holds a lock that the operating system drops the moment the process ends, however it ends: if the next move finds it free, the worker is provably gone and the move is marked interrupted; if the worker cannot be checked (another machine that does not share the data directory), the move stays put until an administrator marks it as interrupted from the list, which is refused while the worker is alive. When Nextcloud's background jobs have not run for over an hour while a move waits (a server without cron, a broken cron entry), the File moves list says so, with the date of the last run, instead of leaving a move "queued" for ever. Needs the two database migrations that come with 0.8.0.

Security

Follow-up to the 0.7.0 review, which found the fixes above incomplete: - A Talk conversation's token still reached an auditor through the Access lookup (the "who can reach this" search): it listed every conversation with its token, took the token back as the lookup key, and an empty recipient listed every Talk share on the instance with the token in each row. The lookup now identifies a conversation to an auditor by an opaque handle (a keyed hash with the instance's secret) and finds it by its name; a token passed in finds nothing, and an empty recipient lists nothing. An admin still gets the token, since an admin may have it. The same hole was open a substring at a time through All shares' search and its recipient filter, and through sorting by recipient: for an auditor those no longer match or order by a conversation's token either (a conversation is still found by its name). - That lookup also ordered its results, and cut them off at twenty, by the conversations' tokens, which is as good as the token to anyone who can create conversations of their own, since every comparison against a token they know is one bit of one they don't (42 comparisons recover eight characters). For an auditor the conversations are now ordered by what is public about them (how many shares, what they are called), with a keyed hash as the last resort, and the search that finds conversations by name is cut off by their id, not their token. - Redacting a token by showing the conversation's name failed for a conversation with no name: the token was its own fallback name, so it came out in the recipient, its display name and its label, in the list, the CSV, the orphan list and the recycle bin. A conversation nobody named is now shown as Unnamed conversation and no field carries its token; the recycle bin shares the one redaction with the other lists instead of keeping its own copy. - Restoring a public link that had a password no longer creates it open for a moment and puts the password back afterwards: it is created protected by a strong temporary password and the original one is swapped in once it exists. This also lets such a link be restored on an instance that enforces passwords for public links, where creating it without one was refused. - Restoring the same recycle-bin entry twice at the same moment (a double click, or two admins) created a link for each request, and each wrote the same original token onto its link: two, three or more live links on one URL, so that revoking the link the owner knew about left the file reachable through the others. A restore now claims the entry first and is one transaction: only one request creates anything, the others are told the entry is gone, and any failure rolls all of it back: the entry stays in the bin, and there is no half-restored link left to clean up. (Checked by racing four simultaneous restores, ten times over: before, all four answered success, on MariaDB and on PostgreSQL; now exactly one does, on both.) - Restoring a link whose original token had since been taken by another share no longer leaves two links on one URL. The database index on the token is not unique, so the restore relied on a constraint that is not there and quietly succeeded; it now checks first, and keeps the link with a new token (or, if it had a password, refuses and keeps the backup, as before). - A restored link could come back with more access than it had. The recycle bin kept a share's permissions, token and password but not hide download nor its download-permission attribute, so a restored link served downloads it had been set to refuse, on the URL already handed out. Both are now kept and put back before the share exists. Entries kept before this version cannot say what they had: a link or mail share from one of them comes back with downloads hidden, and the result says so. - Two live links could end up on one token. Two requests that had each loaded a share before either deleted it left two entries in the bin, and restoring both at the same moment could put the same token on two shares, so revoking one left the URL working through the other. The bin now keeps one entry per share (duplicates already there are dropped when upgrading, keeping the oldest), and a restore holds the link's token until it has committed. - A queued file move could move a different file. The queue kept a path, and whatever was at that path when the job ran was handed over, even if the selected file had been renamed and something else put in its place. The move now checks that the path still holds the file or folder that was selected, and moves nothing (no longer the file or folder that was selected) if not. - The personal view named folders of the owner a user was never given. For a link a user made on something shared with them, My shares and its alerts showed the owner's full path (/Clients/Merger/BoardOnly/report.pdf). They now show the path as that user sees it, or only the file name.

Fixed

• A file move reported "Done" when the Files app could not hand over the shares. The transfer writes a share it failed to update to an output nobody read here and returns as if all went well. After a move, the shares still naming the old owner while their file is now in the new owner's home are looked up: if there are any, the move is Partly done and lists them, to hand over with Only the shares.
• Access lookup and groups. It lists, and Revoke all removes, the shares made directly to a recipient, and now says so (direct shares). For a user it also lists the groups through which they reach shared files (with how many shares each), which revoking the direct shares leaves in place; a user with no share of their own can now be looked up for that too.
• A bulk revoke in Access lookup could move on to another recipient. Each batch read the selected recipient again, so choosing someone else while it ran sent the next batches for them. The recipient confirmed is used for every batch, and search and Back wait for it to finish. Likewise a bulk purge in Deleted shares sends what was ticked when it was confirmed.
• The warning that a revoke left shares behind vanished as the list reloaded.
• A slow answer to an earlier search, filter or page could replace the one asked for last, leaving a list that did not match the filters shown (and an export that did). Only the latest request's answer is shown now.
• Accepting the reason an alert was critical left it sorted among the critical ones, and in the dashboard widget ahead of alerts still critical.
• Searching for 0 in a share list's text filters matched every share.
• Paths in a Team Folder asked Groupfolders for the folder's name once per share; it is now asked once per folder per request.
• A queued file move and its background job are now written together, so a failure between the two can no longer leave a move that never runs.
• Acting on an expired public link deleted it and reported a failure. Every action on a share (revoke, add a password, set an expiration, accept an alert, even the check of who owns it in the personal view) loaded the share through Nextcloud's validity check, which for an expired share deletes it and then throws "the requested share does not exist anymore". So "Revoke all" on links that had expired came back as a failure although it had removed them (they sat in Deleted shares), the same request repeated said "0 of 10 shares updated" about links that were already gone, and a change to an expired link, or an account that did not own it merely asking, could remove it. Shares are now loaded without that check, so revoking an expired link simply works and a bulk revoke reports every one as done. Revoking a share that is already gone counts as done too. A password or a new expiration on an expired link is refused with a clear message (it can only be revoked) instead of deleting it. The same check also hid links whose owner can no longer create links, which an audit has to be able to revoke.
• The exposure map's Other row now has a View button like the others, and asking All shares for an exposure category the app does not have is refused instead of quietly listing everything.
• The dashboard's Internal vs external donut counted every Talk conversation as internal, and the exposure map's Public "View" button opened only public file links, leaving public conversations out of a list that its own count included. Both now come from the same classification as the exposure score, so a category's number and the list behind it are the same shares.
• A Talk conversation the exposure map could not look up (Talk missing, or its tables not what this expects) was counted as internal, so an instance of public conversations could score zero. It is now counted as Other (what could not be classified, weighed like external), never as safe.

Added

• German, Spanish and French translations of the whole interface. French contributed by @QwazarFR (#10).
• Try it in Nextcloud Playground — a one-click, browser-only demo instance (no install required) with Share Audit Dashboard pre-installed and a handful of shares already seeded, so the Dashboard, Security alerts and Lookup & Orphans views have something to show immediately. See the README for the link.
• Jump to a specific page on every paginated list (All shares, Security alerts, Orphan shares, Deleted shares, Access lookup) instead of only stepping one page at a time — useful once a list runs into the hundreds of pages. Contributed by @QwazarFR (#17, fixes #11).

Fixed

• Soft-delete failed for user shares (share_type 0), the most common share type: it silently never landed in the recycle bin — the share was still deleted, only the safety-net copy was lost, with no visible error at the time. Caused by the retention entity's zero-value defaults matching real values (share_type 0, permissions 0, an empty owner) closely enough that Nextcloud's own change-tracking treated setting them as a no-op and omitted the column from the database insert. Thanks @dauni for the precise diagnosis (#15).
• Generating a password for a public link could fail ("The action could not be completed.") on instances where the password_policy app enforces a minimum password length longer than this app's own 14-character default. The generator now generates at least as many characters as the instance's configured policy requires. Thanks @michel-thomas (#9).

Documentation

• Documented a known ARM64 + PHP JIT segfault (opcache tracing JIT) some users hit on enabling the app, with the opcache.jit=0 mitigation. This is a PHP/Zend JIT compiler issue on its ARM64 backend, not an app bug — see #3.

Added

• Soft delete (recycle bin) for shares. A revoked share — whether revoked through this app or unshared through native Nextcloud (Files app, another app, occ, the sharing OCS API) — is now kept for a configurable retention window (default 30 days, Settings → Recycle bin) before being permanently purged, instead of disappearing immediately and irreversibly. New "Deleted shares" tab: restore an entry (recreates the share, and best- effort preserves the original public-link URL and password) or delete it permanently, individually or in bulk. A daily background job purges expired entries. This is the app's first database migration.
• Nextcloud 34 support (max-version raised from 33 to 34).

Fixed

• Sort order is now deterministic across MySQL/MariaDB and PostgreSQL. MySQL sorts NULL before every value and PostgreSQL after it, so sorting the shares table by path, recipient or expiration could return the same rows in a different order on each engine — or, combined with a LIMIT (top sharers, recipient autocomplete), a genuinely different set of rows, since an unbroken tie at the cutoff was decided arbitrarily per engine. Nullable sort columns now get an explicit "nulls last" tiebreaker, and every grouped query paired with a LIMIT has a deterministic secondary sort key. Verified by running an identical fixture against both engines and diffing every read path (build/README.md).

Security

• Share deletion — single, bulk, orphan revoke and recipient revoke-all — now always goes through IShareManager instead of a raw SQL DELETE, so federated unshare (OCM), ShareDeletedEvent and provider-specific cleanup run; a direct DB delete is now only a documented fallback (owner account gone, provider app disabled), and a genuinely retryable failure (a locked file, an unreachable storage backend) is reported back as failed instead of being forced through that fallback.
• Bulk endpoints (revoke, orphan revoke, revoke-all for a recipient) are capped and chunked so an unbounded selection can no longer tie up a PHP worker for minutes; revoke-all for a recipient with a very large number of shares now runs in server-side batches of 500 instead of one synchronous request.
• The security-alerts cache is now invalidated as soon as a link is fixed or revoked, instead of only expiring after its normal TTL — the alerts view no longer shows an already-fixed item as still insecure right after acting on it.
• Minimum supported Nextcloud version raised to 31 — orphan-share revoke relies on IShareManager::getShareById()'s $onlyValid parameter, which does not exist on Nextcloud 30.
• The exposure score no longer treats a share type this version of the app doesn't recognize (e.g. one added in a future Nextcloud release) as safe — it's now weighted the same as an external share instead of falling back to internal, and shown as its own "Other" slice (with an explanatory tooltip) in the exposure breakdown whenever it's non-zero.
• The recipient drill-down's shares/revoke-all endpoints are now rate-limited, matching the same endpoint's search action.

Added

• Portuguese (Portugal) translation of the whole interface, plus build/l10n.py to regenerate the frontend l10n/*.js bundles from the .json sources and report missing or orphaned strings; l10n.py --check now also gates krankerl package.
• Security alerts: copy/open-in-Files actions on individual alerts, and a clearable active-filter indicator.
• All shares: a table caption describing the view.
• Personal view: an option to include link tokens in CSV export, with an explicit warning about what that means.
• Admin setting to turn the personal "My shares audit" page and its dashboard widget off instance-wide, for admins who want sharing audits to stay an admin-only concern.
• Two new configurable security-alert rules: a public link open for anonymous upload without a password (file drop, or full create+update access), and a native group share granting edit or reshare permission to a group above a configurable member-count threshold (default 20).
• The exposure/type "Other" bucket (share types this version doesn't recognize) now shows an explanatory tooltip on the dashboard's "Shares by type" chart and stat cards too, not just the exposure map.

Changed

• Personal view header, summary cards and table captions restyled to match the admin dashboard's look (icon cards, ·-separated header, consistent table styling).

Fixed

• Several UI strings introduced alongside the above were missing from l10n/*.json, so pt_PT users saw English text on the newest features.
• The "with expiration" / "without expiration" filter (All shares column filter, and the underlying flag used by exports) now treats an already-expired date as "without expiration" instead of counting it as still protected.

Fixed

• The auditor's read-only view (issue #16) could not be scrolled on Dashboard, All shares or Security alerts — the page clipped instead of showing a scrollbar, making the lower part of those views unreachable. Lookup & Orphans and Deleted shares were unaffected because their content already fit on screen.
• The Share Audit icon in the top app menu rendered white and was barely visible against a light Nextcloud header.

Added

• Move the files of an orphan share's owner, not just the share. A share whose file sits in a disabled account's own home used to be skipped (The new owner cannot access the file) with a note to run occ files:transfer-ownership by hand. The transfer picker in Orphan shares now asks what to move: only the shares (as before), the shares and the files they point to, or everything the account owns. A file move is the Files app's own ownership transfer, so the shares of what moves follow it, keeping their id and, for a link, the same URL. It runs in a background job and a File moves list under the table shows each one as queued, running, done or failed (with the reason), visible to auditors too. Moving a whole account asks for confirmation first (naming exactly the accounts that will be moved) and every move is written to the audit log. A deleted account has nothing to move (its files went with it), and the conditions are checked again when the job runs: an account that has been re-enabled in the meantime keeps its files. Talk, mail and federated shares go along with their file too, not only link, user and group shares. Only one move into a given account runs at a time, however many background workers Nextcloud has started (the database enforces it); a move that finds the account busy tries again a minute later. That matters because the Files app puts what it moves into a folder named after the second and deletes what it finds at a name that already exists, so two simultaneous moves would erase each other's files of the same name. A move that is running is never given up on because of how long it has been running: a very large folder is indistinguishable from a dead worker by age, and freeing the account while it is still writing to it is the data loss all this prevents. Instead a worker holds a lock that the operating system drops the moment the process ends, however it ends: if the next move finds it free, the worker is provably gone and the move is marked interrupted; if the worker cannot be checked (another machine that does not share the data directory), the move stays put until an administrator marks it as interrupted from the list, which is refused while the worker is alive. When Nextcloud's background jobs have not run for over an hour while a move waits (a server without cron, a broken cron entry), the File moves list says so, with the date of the last run, instead of leaving a move "queued" for ever. Needs the two database migrations that come with 0.8.0.

Security

Follow-up to the 0.7.0 review, which found the fixes above incomplete: - A Talk conversation's token still reached an auditor through the Access lookup (the "who can reach this" search): it listed every conversation with its token, took the token back as the lookup key, and an empty recipient listed every Talk share on the instance with the token in each row. The lookup now identifies a conversation to an auditor by an opaque handle (a keyed hash with the instance's secret) and finds it by its name; a token passed in finds nothing, and an empty recipient lists nothing. An admin still gets the token, since an admin may have it. The same hole was open a substring at a time through All shares' search and its recipient filter, and through sorting by recipient: for an auditor those no longer match or order by a conversation's token either (a conversation is still found by its name). - That lookup also ordered its results, and cut them off at twenty, by the conversations' tokens, which is as good as the token to anyone who can create conversations of their own, since every comparison against a token they know is one bit of one they don't (42 comparisons recover eight characters). For an auditor the conversations are now ordered by what is public about them (how many shares, what they are called), with a keyed hash as the last resort, and the search that finds conversations by name is cut off by their id, not their token. - Redacting a token by showing the conversation's name failed for a conversation with no name: the token was its own fallback name, so it came out in the recipient, its display name and its label, in the list, the CSV, the orphan list and the recycle bin. A conversation nobody named is now shown as Unnamed conversation and no field carries its token; the recycle bin shares the one redaction with the other lists instead of keeping its own copy. - Restoring a public link that had a password no longer creates it open for a moment and puts the password back afterwards: it is created protected by a strong temporary password and the original one is swapped in once it exists. This also lets such a link be restored on an instance that enforces passwords for public links, where creating it without one was refused. - Restoring the same recycle-bin entry twice at the same moment (a double click, or two admins) created a link for each request, and each wrote the same original token onto its link: two, three or more live links on one URL, so that revoking the link the owner knew about left the file reachable through the others. A restore now claims the entry first and is one transaction: only one request creates anything, the others are told the entry is gone, and any failure rolls all of it back: the entry stays in the bin, and there is no half-restored link left to clean up. (Checked by racing four simultaneous restores, ten times over: before, all four answered success, on MariaDB and on PostgreSQL; now exactly one does, on both.) - Restoring a link whose original token had since been taken by another share no longer leaves two links on one URL. The database index on the token is not unique, so the restore relied on a constraint that is not there and quietly succeeded; it now checks first, and keeps the link with a new token (or, if it had a password, refuses and keeps the backup, as before). - A restored link could come back with more access than it had. The recycle bin kept a share's permissions, token and password but not hide download nor its download-permission attribute, so a restored link served downloads it had been set to refuse, on the URL already handed out. Both are now kept and put back before the share exists. Entries kept before this version cannot say what they had: a link or mail share from one of them comes back with downloads hidden, and the result says so. - Two live links could end up on one token. Two requests that had each loaded a share before either deleted it left two entries in the bin, and restoring both at the same moment could put the same token on two shares, so revoking one left the URL working through the other. The bin now keeps one entry per share (duplicates already there are dropped when upgrading, keeping the oldest), and a restore holds the link's token until it has committed. - A queued file move could move a different file. The queue kept a path, and whatever was at that path when the job ran was handed over, even if the selected file had been renamed and something else put in its place. The move now checks that the path still holds the file or folder that was selected, and moves nothing (no longer the file or folder that was selected) if not. - The personal view named folders of the owner a user was never given. For a link a user made on something shared with them, My shares and its alerts showed the owner's full path (/Clients/Merger/BoardOnly/report.pdf). They now show the path as that user sees it, or only the file name.

Fixed

• A file move reported "Done" when the Files app could not hand over the shares. The transfer writes a share it failed to update to an output nobody read here and returns as if all went well. After a move, the shares still naming the old owner while their file is now in the new owner's home are looked up: if there are any, the move is Partly done and lists them, to hand over with Only the shares.
• Access lookup and groups. It lists, and Revoke all removes, the shares made directly to a recipient, and now says so (direct shares). For a user it also lists the groups through which they reach shared files (with how many shares each), which revoking the direct shares leaves in place; a user with no share of their own can now be looked up for that too.
• A bulk revoke in Access lookup could move on to another recipient. Each batch read the selected recipient again, so choosing someone else while it ran sent the next batches for them. The recipient confirmed is used for every batch, and search and Back wait for it to finish. Likewise a bulk purge in Deleted shares sends what was ticked when it was confirmed.
• The warning that a revoke left shares behind vanished as the list reloaded.
• A slow answer to an earlier search, filter or page could replace the one asked for last, leaving a list that did not match the filters shown (and an export that did). Only the latest request's answer is shown now.
• Accepting the reason an alert was critical left it sorted among the critical ones, and in the dashboard widget ahead of alerts still critical.
• Searching for 0 in a share list's text filters matched every share.
• Paths in a Team Folder asked Groupfolders for the folder's name once per share; it is now asked once per folder per request.
• A queued file move and its background job are now written together, so a failure between the two can no longer leave a move that never runs.
• Acting on an expired public link deleted it and reported a failure. Every action on a share (revoke, add a password, set an expiration, accept an alert, even the check of who owns it in the personal view) loaded the share through Nextcloud's validity check, which for an expired share deletes it and then throws "the requested share does not exist anymore". So "Revoke all" on links that had expired came back as a failure although it had removed them (they sat in Deleted shares), the same request repeated said "0 of 10 shares updated" about links that were already gone, and a change to an expired link, or an account that did not own it merely asking, could remove it. Shares are now loaded without that check, so revoking an expired link simply works and a bulk revoke reports every one as done. Revoking a share that is already gone counts as done too. A password or a new expiration on an expired link is refused with a clear message (it can only be revoked) instead of deleting it. The same check also hid links whose owner can no longer create links, which an audit has to be able to revoke.
• The exposure map's Other row now has a View button like the others, and asking All shares for an exposure category the app does not have is refused instead of quietly listing everything.
• The dashboard's Internal vs external donut counted every Talk conversation as internal, and the exposure map's Public "View" button opened only public file links, leaving public conversations out of a list that its own count included. Both now come from the same classification as the exposure score, so a category's number and the list behind it are the same shares.
• A Talk conversation the exposure map could not look up (Talk missing, or its tables not what this expects) was counted as internal, so an instance of public conversations could score zero. It is now counted as Other (what could not be classified, weighed like external), never as safe.

Added

• German, Spanish and French translations of the whole interface. French contributed by @QwazarFR (#10).
• Try it in Nextcloud Playground — a one-click, browser-only demo instance (no install required) with Share Audit Dashboard pre-installed and a handful of shares already seeded, so the Dashboard, Security alerts and Lookup & Orphans views have something to show immediately. See the README for the link.
• Jump to a specific page on every paginated list (All shares, Security alerts, Orphan shares, Deleted shares, Access lookup) instead of only stepping one page at a time — useful once a list runs into the hundreds of pages. Contributed by @QwazarFR (#17, fixes #11).

Fixed

• Soft-delete failed for user shares (share_type 0), the most common share type: it silently never landed in the recycle bin — the share was still deleted, only the safety-net copy was lost, with no visible error at the time. Caused by the retention entity's zero-value defaults matching real values (share_type 0, permissions 0, an empty owner) closely enough that Nextcloud's own change-tracking treated setting them as a no-op and omitted the column from the database insert. Thanks @dauni for the precise diagnosis (#15).
• Generating a password for a public link could fail ("The action could not be completed.") on instances where the password_policy app enforces a minimum password length longer than this app's own 14-character default. The generator now generates at least as many characters as the instance's configured policy requires. Thanks @michel-thomas (#9).

Documentation

• Documented a known ARM64 + PHP JIT segfault (opcache tracing JIT) some users hit on enabling the app, with the opcache.jit=0 mitigation. This is a PHP/Zend JIT compiler issue on its ARM64 backend, not an app bug — see #3.

Added

• Soft delete (recycle bin) for shares. A revoked share — whether revoked through this app or unshared through native Nextcloud (Files app, another app, occ, the sharing OCS API) — is now kept for a configurable retention window (default 30 days, Settings → Recycle bin) before being permanently purged, instead of disappearing immediately and irreversibly. New "Deleted shares" tab: restore an entry (recreates the share, and best- effort preserves the original public-link URL and password) or delete it permanently, individually or in bulk. A daily background job purges expired entries. This is the app's first database migration.
• Nextcloud 34 support (max-version raised from 33 to 34).

Fixed

• Sort order is now deterministic across MySQL/MariaDB and PostgreSQL. MySQL sorts NULL before every value and PostgreSQL after it, so sorting the shares table by path, recipient or expiration could return the same rows in a different order on each engine — or, combined with a LIMIT (top sharers, recipient autocomplete), a genuinely different set of rows, since an unbroken tie at the cutoff was decided arbitrarily per engine. Nullable sort columns now get an explicit "nulls last" tiebreaker, and every grouped query paired with a LIMIT has a deterministic secondary sort key. Verified by running an identical fixture against both engines and diffing every read path (build/README.md).

Security

• Share deletion — single, bulk, orphan revoke and recipient revoke-all — now always goes through IShareManager instead of a raw SQL DELETE, so federated unshare (OCM), ShareDeletedEvent and provider-specific cleanup run; a direct DB delete is now only a documented fallback (owner account gone, provider app disabled), and a genuinely retryable failure (a locked file, an unreachable storage backend) is reported back as failed instead of being forced through that fallback.
• Bulk endpoints (revoke, orphan revoke, revoke-all for a recipient) are capped and chunked so an unbounded selection can no longer tie up a PHP worker for minutes; revoke-all for a recipient with a very large number of shares now runs in server-side batches of 500 instead of one synchronous request.
• The security-alerts cache is now invalidated as soon as a link is fixed or revoked, instead of only expiring after its normal TTL — the alerts view no longer shows an already-fixed item as still insecure right after acting on it.
• Minimum supported Nextcloud version raised to 31 — orphan-share revoke relies on IShareManager::getShareById()'s $onlyValid parameter, which does not exist on Nextcloud 30.
• The exposure score no longer treats a share type this version of the app doesn't recognize (e.g. one added in a future Nextcloud release) as safe — it's now weighted the same as an external share instead of falling back to internal, and shown as its own "Other" slice (with an explanatory tooltip) in the exposure breakdown whenever it's non-zero.
• The recipient drill-down's shares/revoke-all endpoints are now rate-limited, matching the same endpoint's search action.

Added

• Portuguese (Portugal) translation of the whole interface, plus build/l10n.py to regenerate the frontend l10n/*.js bundles from the .json sources and report missing or orphaned strings; l10n.py --check now also gates krankerl package.
• Security alerts: copy/open-in-Files actions on individual alerts, and a clearable active-filter indicator.
• All shares: a table caption describing the view.
• Personal view: an option to include link tokens in CSV export, with an explicit warning about what that means.
• Admin setting to turn the personal "My shares audit" page and its dashboard widget off instance-wide, for admins who want sharing audits to stay an admin-only concern.
• Two new configurable security-alert rules: a public link open for anonymous upload without a password (file drop, or full create+update access), and a native group share granting edit or reshare permission to a group above a configurable member-count threshold (default 20).
• The exposure/type "Other" bucket (share types this version doesn't recognize) now shows an explanatory tooltip on the dashboard's "Shares by type" chart and stat cards too, not just the exposure map.

Changed

• Personal view header, summary cards and table captions restyled to match the admin dashboard's look (icon cards, ·-separated header, consistent table styling).

Fixed

• Several UI strings introduced alongside the above were missing from l10n/*.json, so pt_PT users saw English text on the newest features.
• The "with expiration" / "without expiration" filter (All shares column filter, and the underlying flag used by exports) now treats an already-expired date as "without expiration" instead of counting it as still protected.

Fixed

• The auditor's read-only view (issue #16) could not be scrolled on Dashboard, All shares or Security alerts — the page clipped instead of showing a scrollbar, making the lower part of those views unreachable. Lookup & Orphans and Deleted shares were unaffected because their content already fit on screen.
• The Share Audit icon in the top app menu rendered white and was barely visible against a light Nextcloud header.

Added

• Move the files of an orphan share's owner, not just the share. A share whose file sits in a disabled account's own home used to be skipped (The new owner cannot access the file) with a note to run occ files:transfer-ownership by hand. The transfer picker in Orphan shares now asks what to move: only the shares (as before), the shares and the files they point to, or everything the account owns. A file move is the Files app's own ownership transfer, so the shares of what moves follow it, keeping their id and, for a link, the same URL. It runs in a background job and a File moves list under the table shows each one as queued, running, done or failed (with the reason), visible to auditors too. Moving a whole account asks for confirmation first (naming exactly the accounts that will be moved) and every move is written to the audit log. A deleted account has nothing to move (its files went with it), and the conditions are checked again when the job runs: an account that has been re-enabled in the meantime keeps its files. Talk, mail and federated shares go along with their file too, not only link, user and group shares. Only one move into a given account runs at a time, however many background workers Nextcloud has started (the database enforces it); a move that finds the account busy tries again a minute later. That matters because the Files app puts what it moves into a folder named after the second and deletes what it finds at a name that already exists, so two simultaneous moves would erase each other's files of the same name. A move that is running is never given up on because of how long it has been running: a very large folder is indistinguishable from a dead worker by age, and freeing the account while it is still writing to it is the data loss all this prevents. Instead a worker holds a lock that the operating system drops the moment the process ends, however it ends: if the next move finds it free, the worker is provably gone and the move is marked interrupted; if the worker cannot be checked (another machine that does not share the data directory), the move stays put until an administrator marks it as interrupted from the list, which is refused while the worker is alive. When Nextcloud's background jobs have not run for over an hour while a move waits (a server without cron, a broken cron entry), the File moves list says so, with the date of the last run, instead of leaving a move "queued" for ever. Needs the two database migrations that come with 0.8.0.

Security

Follow-up to the 0.7.0 review, which found the fixes above incomplete: - A Talk conversation's token still reached an auditor through the Access lookup (the "who can reach this" search): it listed every conversation with its token, took the token back as the lookup key, and an empty recipient listed every Talk share on the instance with the token in each row. The lookup now identifies a conversation to an auditor by an opaque handle (a keyed hash with the instance's secret) and finds it by its name; a token passed in finds nothing, and an empty recipient lists nothing. An admin still gets the token, since an admin may have it. The same hole was open a substring at a time through All shares' search and its recipient filter, and through sorting by recipient: for an auditor those no longer match or order by a conversation's token either (a conversation is still found by its name). - That lookup also ordered its results, and cut them off at twenty, by the conversations' tokens, which is as good as the token to anyone who can create conversations of their own, since every comparison against a token they know is one bit of one they don't (42 comparisons recover eight characters). For an auditor the conversations are now ordered by what is public about them (how many shares, what they are called), with a keyed hash as the last resort, and the search that finds conversations by name is cut off by their id, not their token. - Redacting a token by showing the conversation's name failed for a conversation with no name: the token was its own fallback name, so it came out in the recipient, its display name and its label, in the list, the CSV, the orphan list and the recycle bin. A conversation nobody named is now shown as Unnamed conversation and no field carries its token; the recycle bin shares the one redaction with the other lists instead of keeping its own copy. - Restoring a public link that had a password no longer creates it open for a moment and puts the password back afterwards: it is created protected by a strong temporary password and the original one is swapped in once it exists. This also lets such a link be restored on an instance that enforces passwords for public links, where creating it without one was refused. - Restoring the same recycle-bin entry twice at the same moment (a double click, or two admins) created a link for each request, and each wrote the same original token onto its link: two, three or more live links on one URL, so that revoking the link the owner knew about left the file reachable through the others. A restore now claims the entry first and is one transaction: only one request creates anything, the others are told the entry is gone, and any failure rolls all of it back: the entry stays in the bin, and there is no half-restored link left to clean up. (Checked by racing four simultaneous restores, ten times over: before, all four answered success, on MariaDB and on PostgreSQL; now exactly one does, on both.) - Restoring a link whose original token had since been taken by another share no longer leaves two links on one URL. The database index on the token is not unique, so the restore relied on a constraint that is not there and quietly succeeded; it now checks first, and keeps the link with a new token (or, if it had a password, refuses and keeps the backup, as before). - A restored link could come back with more access than it had. The recycle bin kept a share's permissions, token and password but not hide download nor its download-permission attribute, so a restored link served downloads it had been set to refuse, on the URL already handed out. Both are now kept and put back before the share exists. Entries kept before this version cannot say what they had: a link or mail share from one of them comes back with downloads hidden, and the result says so. - Two live links could end up on one token. Two requests that had each loaded a share before either deleted it left two entries in the bin, and restoring both at the same moment could put the same token on two shares, so revoking one left the URL working through the other. The bin now keeps one entry per share (duplicates already there are dropped when upgrading, keeping the oldest), and a restore holds the link's token until it has committed. - A queued file move could move a different file. The queue kept a path, and whatever was at that path when the job ran was handed over, even if the selected file had been renamed and something else put in its place. The move now checks that the path still holds the file or folder that was selected, and moves nothing (no longer the file or folder that was selected) if not. - The personal view named folders of the owner a user was never given. For a link a user made on something shared with them, My shares and its alerts showed the owner's full path (/Clients/Merger/BoardOnly/report.pdf). They now show the path as that user sees it, or only the file name.

Fixed

• A file move reported "Done" when the Files app could not hand over the shares. The transfer writes a share it failed to update to an output nobody read here and returns as if all went well. After a move, the shares still naming the old owner while their file is now in the new owner's home are looked up: if there are any, the move is Partly done and lists them, to hand over with Only the shares.
• Access lookup and groups. It lists, and Revoke all removes, the shares made directly to a recipient, and now says so (direct shares). For a user it also lists the groups through which they reach shared files (with how many shares each), which revoking the direct shares leaves in place; a user with no share of their own can now be looked up for that too.
• A bulk revoke in Access lookup could move on to another recipient. Each batch read the selected recipient again, so choosing someone else while it ran sent the next batches for them. The recipient confirmed is used for every batch, and search and Back wait for it to finish. Likewise a bulk purge in Deleted shares sends what was ticked when it was confirmed.
• The warning that a revoke left shares behind vanished as the list reloaded.
• A slow answer to an earlier search, filter or page could replace the one asked for last, leaving a list that did not match the filters shown (and an export that did). Only the latest request's answer is shown now.
• Accepting the reason an alert was critical left it sorted among the critical ones, and in the dashboard widget ahead of alerts still critical.
• Searching for 0 in a share list's text filters matched every share.
• Paths in a Team Folder asked Groupfolders for the folder's name once per share; it is now asked once per folder per request.
• A queued file move and its background job are now written together, so a failure between the two can no longer leave a move that never runs.
• Acting on an expired public link deleted it and reported a failure. Every action on a share (revoke, add a password, set an expiration, accept an alert, even the check of who owns it in the personal view) loaded the share through Nextcloud's validity check, which for an expired share deletes it and then throws "the requested share does not exist anymore". So "Revoke all" on links that had expired came back as a failure although it had removed them (they sat in Deleted shares), the same request repeated said "0 of 10 shares updated" about links that were already gone, and a change to an expired link, or an account that did not own it merely asking, could remove it. Shares are now loaded without that check, so revoking an expired link simply works and a bulk revoke reports every one as done. Revoking a share that is already gone counts as done too. A password or a new expiration on an expired link is refused with a clear message (it can only be revoked) instead of deleting it. The same check also hid links whose owner can no longer create links, which an audit has to be able to revoke.
• The exposure map's Other row now has a View button like the others, and asking All shares for an exposure category the app does not have is refused instead of quietly listing everything.
• The dashboard's Internal vs external donut counted every Talk conversation as internal, and the exposure map's Public "View" button opened only public file links, leaving public conversations out of a list that its own count included. Both now come from the same classification as the exposure score, so a category's number and the list behind it are the same shares.
• A Talk conversation the exposure map could not look up (Talk missing, or its tables not what this expects) was counted as internal, so an instance of public conversations could score zero. It is now counted as Other (what could not be classified, weighed like external), never as safe.

Added

• German, Spanish and French translations of the whole interface. French contributed by @QwazarFR (#10).
• Try it in Nextcloud Playground — a one-click, browser-only demo instance (no install required) with Share Audit Dashboard pre-installed and a handful of shares already seeded, so the Dashboard, Security alerts and Lookup & Orphans views have something to show immediately. See the README for the link.
• Jump to a specific page on every paginated list (All shares, Security alerts, Orphan shares, Deleted shares, Access lookup) instead of only stepping one page at a time — useful once a list runs into the hundreds of pages. Contributed by @QwazarFR (#17, fixes #11).

Fixed

• Soft-delete failed for user shares (share_type 0), the most common share type: it silently never landed in the recycle bin — the share was still deleted, only the safety-net copy was lost, with no visible error at the time. Caused by the retention entity's zero-value defaults matching real values (share_type 0, permissions 0, an empty owner) closely enough that Nextcloud's own change-tracking treated setting them as a no-op and omitted the column from the database insert. Thanks @dauni for the precise diagnosis (#15).
• Generating a password for a public link could fail ("The action could not be completed.") on instances where the password_policy app enforces a minimum password length longer than this app's own 14-character default. The generator now generates at least as many characters as the instance's configured policy requires. Thanks @michel-thomas (#9).

Documentation

• Documented a known ARM64 + PHP JIT segfault (opcache tracing JIT) some users hit on enabling the app, with the opcache.jit=0 mitigation. This is a PHP/Zend JIT compiler issue on its ARM64 backend, not an app bug — see #3.

Added

• Soft delete (recycle bin) for shares. A revoked share — whether revoked through this app or unshared through native Nextcloud (Files app, another app, occ, the sharing OCS API) — is now kept for a configurable retention window (default 30 days, Settings → Recycle bin) before being permanently purged, instead of disappearing immediately and irreversibly. New "Deleted shares" tab: restore an entry (recreates the share, and best- effort preserves the original public-link URL and password) or delete it permanently, individually or in bulk. A daily background job purges expired entries. This is the app's first database migration.
• Nextcloud 34 support (max-version raised from 33 to 34).

Fixed

• Sort order is now deterministic across MySQL/MariaDB and PostgreSQL. MySQL sorts NULL before every value and PostgreSQL after it, so sorting the shares table by path, recipient or expiration could return the same rows in a different order on each engine — or, combined with a LIMIT (top sharers, recipient autocomplete), a genuinely different set of rows, since an unbroken tie at the cutoff was decided arbitrarily per engine. Nullable sort columns now get an explicit "nulls last" tiebreaker, and every grouped query paired with a LIMIT has a deterministic secondary sort key. Verified by running an identical fixture against both engines and diffing every read path (build/README.md).

Security

• Share deletion — single, bulk, orphan revoke and recipient revoke-all — now always goes through IShareManager instead of a raw SQL DELETE, so federated unshare (OCM), ShareDeletedEvent and provider-specific cleanup run; a direct DB delete is now only a documented fallback (owner account gone, provider app disabled), and a genuinely retryable failure (a locked file, an unreachable storage backend) is reported back as failed instead of being forced through that fallback.
• Bulk endpoints (revoke, orphan revoke, revoke-all for a recipient) are capped and chunked so an unbounded selection can no longer tie up a PHP worker for minutes; revoke-all for a recipient with a very large number of shares now runs in server-side batches of 500 instead of one synchronous request.
• The security-alerts cache is now invalidated as soon as a link is fixed or revoked, instead of only expiring after its normal TTL — the alerts view no longer shows an already-fixed item as still insecure right after acting on it.
• Minimum supported Nextcloud version raised to 31 — orphan-share revoke relies on IShareManager::getShareById()'s $onlyValid parameter, which does not exist on Nextcloud 30.
• The exposure score no longer treats a share type this version of the app doesn't recognize (e.g. one added in a future Nextcloud release) as safe — it's now weighted the same as an external share instead of falling back to internal, and shown as its own "Other" slice (with an explanatory tooltip) in the exposure breakdown whenever it's non-zero.
• The recipient drill-down's shares/revoke-all endpoints are now rate-limited, matching the same endpoint's search action.

Added

• Portuguese (Portugal) translation of the whole interface, plus build/l10n.py to regenerate the frontend l10n/*.js bundles from the .json sources and report missing or orphaned strings; l10n.py --check now also gates krankerl package.
• Security alerts: copy/open-in-Files actions on individual alerts, and a clearable active-filter indicator.
• All shares: a table caption describing the view.
• Personal view: an option to include link tokens in CSV export, with an explicit warning about what that means.
• Admin setting to turn the personal "My shares audit" page and its dashboard widget off instance-wide, for admins who want sharing audits to stay an admin-only concern.
• Two new configurable security-alert rules: a public link open for anonymous upload without a password (file drop, or full create+update access), and a native group share granting edit or reshare permission to a group above a configurable member-count threshold (default 20).
• The exposure/type "Other" bucket (share types this version doesn't recognize) now shows an explanatory tooltip on the dashboard's "Shares by type" chart and stat cards too, not just the exposure map.

Changed

• Personal view header, summary cards and table captions restyled to match the admin dashboard's look (icon cards, ·-separated header, consistent table styling).

Fixed

• Several UI strings introduced alongside the above were missing from l10n/*.json, so pt_PT users saw English text on the newest features.
• The "with expiration" / "without expiration" filter (All shares column filter, and the underlying flag used by exports) now treats an already-expired date as "without expiration" instead of counting it as still protected.