🧾Add share metadata#8069
Conversation
AndyScherzinger
force-pushed
the
feat/noid/share-metadata
branch
5 times, most recently
from
fc93f49 to
e83b66e
Compare
…s to deck_board_acl Assisted-by: Claude Code:claude-sonnet-4-6 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
…re timestamps on upgrade Assisted-by: Claude Code:claude-sonnet-4-6 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
…cl insert and update Assisted-by: Claude Code:claude-sonnet-4-6 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
…pper timestamp behaviour Assisted-by: Claude Code:claude-sonnet-4-6 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
…uped IN-clause batches Assisted-by: Claude Code:claude-sonnet-4-6 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
AndyScherzinger
force-pushed
the
feat/noid/share-metadata
branch
2 times, most recently
from
e7ede00 to
af1f803
Compare
Assisted-by: Claude Code:claude-sonnet-4-6 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
AndyScherzinger
force-pushed
the
feat/noid/share-metadata
branch
from
af1f803 to
7e3e603
Compare
AndyScherzinger
requested review from
grnd-alt and
luka-nextcloud
as code owners
| $now = time(); | ||
| $groups = []; | ||
| foreach ($rows as $row) { | ||
| $timestamp = ((int)$row['board_last_modified'] > 0) ? (int)$row['board_last_modified'] : $now; |
There was a problem hiding this comment.
idk if we should really backfill that way, does the app you're doing all that for not have an option to have an unknown value?
The values we're writing in here 99% of the time are not the real created/last_modified of the acl, so an unknown value would be better imo, or at least just the "now" value so it is clear that the value was written when the update was done.
There was a problem hiding this comment.
We can use any we would want, the share review app would else have to assume one and either that is a fully hard-coded and fixed date, no matter the share, or needs to be computed each time the shares are loaded for review. So to me, compute-once made the most sense and going with a creation/modification date of the board itself seemed most feasible. However we could also go for $now if you think that would be better. But in any care I suggest to pre-compute and migrate to a date and not have a fallback logic because we lacked dates in the past.
WDYT @grnd-alt @blizzz ? "No date" feels wrong to me, but that might be me, than we can also just leave it at 0 and take that as "unknown".
Both has its advantages, one is unknown: cause it hasn't been tracked but mid-term I find this confusing to users when there are shares with known and unknown dates.
Both works for me. I can find a way to explain the unknown in the review app of course.
2 participants
Summary
While starting to work on #8052 (nowhere near completion..) to implement the sdhare review capability I realized that the share date always matched 1970 and digging and asking @grnd-alt it turned out deck shares have no creation and no last-edit date, like for example files/folder or tables shares. Yet for a share review app, that also stores a "review date" such timestamps are important to show a changed share for a re-review in case it changed. Hence creation and edit dates a crucial.
TODO
Checklist
🤖 AI (if applicable)