User Details
- User Since
- Mar 19 2025, 8:18 PM (63 w, 4 d)
- Availability
- Available
- LDAP User
- Daanvr
- MediaWiki User
- Daanvr [ Global Accounts ]
Wed, May 20
Sun, May 17
Sat, May 16
Addressed all six points from your 09:34 comment in two new commits on !54 (72299f2 + 124229e — base 7a1d8ad preserved as you asked).
- Pre-deciding ambiguous design questions before implementation accelerated this MR significantly. The maintainer's Q-1/Q-2/Q-3 answers on the task — Q-1 (full scope = removal + new templates + per-param docs), Q-2 (silent fallback for legacy id: 'Custom', no migration banner), Q-3 (fix the !49 entry point in this MR) — meant the implementer hit zero blocking decisions during the build-out. Tasks that have shape-affecting questions ("how should we handle X stored value?") benefit from this pattern: groom the task with explicit Q/A pairs at the top so the implementer knows the decisions are made and doesn't have to re-litigate them. Worth carrying forward to future scope-removal tasks that touch persisted user data.
- Mid-flight scope collision with a peer MR (!49 / T426421) was caught early but only by accident. T426421 ("+ Add column" popover) landed *during* this MR's implementation cycle and added a fourth entry-point ("Custom wikitext-template column") to the very thing this MR was removing. The Q-3 pre-decision handled it cleanly (fix the entry-point in this MR) but only because the maintainer was reviewing both tasks concurrently and noticed the conflict. The systemic gotcha: in-flight MRs that touch the same UI surface can silently re-add what another MR is removing — and per-branch CI won't catch it. Mitigations going forward: when grooming a removal task, scan in-flight MRs (glab mr list) for the same surface area, and have the implementer skim those diffs as part of pre-work.
- Cross-MR conflict surfaced only at merge time, but the local merge-result build caught it cleanly. This MR was rebased before !52 (T426422, per-language Caption columns) landed, so getAllColumns in src/table.jsx had two simultaneous mutations: HEAD's filter-out-kind:'template' (T426449) and origin/main's new captionExtras (T426422). Three-way merge produced a conflict marker. Resolution was straightforward (keep both: HEAD's filter and origin/main's captionExtras in the return) but it surfaced only during the merger's pre-merge local rebase + build — neither per-branch CI run could have caught it because each branch was syntactically valid in isolation. Re-confirms the existing CLAUDE.md rule that mergers must rebuild against the merge result locally; no new durable rule needed.
- Shared-helper DRY opportunity exists for follow-up. The feedback modal reuses the v0.28.0 "Report this error" window.open plumbing (Phabricator pre-fill + User talk:Daanvr section-new flow) but does so by copying the URL-construction code rather than extracting it into a shared helper. With two callers in tree and a third anticipated for any future "report" channel, this is now worth refactoring — a small src/ui/report-channels.js (or similar) wrapping the URL construction and clipboard handoff would tighten both call sites. Not blocking, but worth a follow-up task.
- Re-test the preview after every feedback round. This MR went through three review rounds (top-centre move; richer context + prompts; feedback-type radio). Mid-cycle pushes didn't re-exercise the live preview between rounds, so visual regressions could have slipped through the textual diff. For UI MRs with multiple iterations, walking the preview after each push (not just after the first one) is cheap insurance.
- Mount at <Root> (outside <ErrorBoundary>) to survive boot/render crashes. The FAB is intentionally outside the error boundary so users can still file feedback when the main app has crashed at boot. window.uwbDiagnostics is a clean way to publish current state to a sibling-of-Root component without prop-drilling — that pattern generalizes to other always-available widgets (status badges, etc.) but should not be abused for application state.
Uh some new new feedback is that the um file name suggestions are still overlapping the Suggestions for chips. So whenever the chips menu is activated, the file name suggestions should be disappearing. uh and I give you a screenshot about this to give you a bit more context. Then the um plus chip button at the end of the the the input field um should not say chip because that's the technical term but it should say variable That's logical for the user. Also the chip design is a bit buggy right now. has two like pill shaped uh borders inside of each other. Um this is incorrect and should be normalized. Keep in mind the other chips. Uh and also I would like to be able to reorder the chips um by drag and dropping. And I want there to be a white space in between each chip by default Such that they when you add new ones they don't touch each other.
And an other user experience annoyance is that you're Changes don't get saved whenever you unfocus on that cell. Meaning if you click outside of the cell, all changes disappear. That should not be the case, that is never the case in this table.
overlaping suggestions:
chip design and +chip button
Picked up after maintainer's resume signal in comment 11927794 ("auto-sequence concept becomes 'just another chip kind' inside the new editor", "integrating T425984 code into this code, then publish whilst overwriting previous T425984 code").
the answer is: the auto-sequence concept become "just another chip kind" inside the new editor.
So the use of the hashtag uh as the last character in um the string will still trigger it. Uh and um you can still add the the the numbering. You can also add it from um the uh From the list of suggestions from chips, but it should all work on the same um New editor with the chips uh system. So it should have the same code style and should have the same uh uh work the same thing. It's just a uh uh a bit of a special chip, I guess, because it has some different actions uh and will not directly resolve to Actually it should ac uh uh resolve to numbering. Um but it should clearly still indicate it's part of this um sequence scheme.
Merged as v0.37.0 via !52. Live at https://upload-workbench.toolforge.org/ and permanent archive at https://upload-workbench.toolforge.org/v0.37.0/.
Address-feedback round 2 on !56:
Addressed feedback: the Custom wikitext-template column entry in the "+ Add column" popover was still in the committed code on this branch (the prior agent had it as unstaged work but never committed). New commit 5bee7da deletes it along with the onOpenCustomTemplateForm prop, the colMenuCustomFormOpen tri-state, and the initialCustomFormOpen prop on ColumnsModal that only the now-gone entry-point ever set.
@Daanvr Re your 06:30 ask — here is the same situation explained without code-specific references. The previous comment was right that a maintainer-level design call is needed; this one tries to lay out what the call is about so you can make it deliberately.
explaine the technical considerations in more generic termis insted of the specific functions ore code peaces since i am not nose deep in the codebut want to understand and make a good and deliberate decision that makes sense in a strategic cense fro the code.
no changes visible in the frontend. of !56
this feedback still aplies:
nice! lets move it to the top center of the page and keep it sticky always in sight.
And lets try to enrich the text further with relevant context for trubelshooting bugs or so. and lets ad some inspirational questions fo the user to guide the user to the right a rich and complete bug description of it is about a bug.
please also remove the custom wikitext template column button form the add new column dropdown at the end of the table
Fri, May 15
Skipped during bulk-merge orchestration (5 sibling MRs landed today as v0.32.0–v0.36.0). The rebase of !54 onto current main produces ~500 lines of conflict in src/table.jsx against the auto-sequence work that landed in v0.33.0 (T425984): !54 replaces TitleEditor's state model (v → {rendered, segments}) and the sequence-suggestion logic from T425984 is woven into the pre-chip v-based editor (placeholder gating, ownership-based suppression, etc.). Merging !54 as-is would silently drop the auto-sequence integration with the title editor — a regression of T425984.
Merged as v0.36.0 via !58. Live at https://upload-workbench.toolforge.org/ and permanent archive at https://upload-workbench.toolforge.org/v0.36.0/.
Merged as v0.35.0 via !57. Live at https://upload-workbench.toolforge.org/ and permanent archive at https://upload-workbench.toolforge.org/v0.35.0/.
Merged as v0.34.0 via !50. Live at https://upload-workbench.toolforge.org/ and permanent archive at https://upload-workbench.toolforge.org/v0.34.0/.
Merged as v0.33.0 via !51. Live at https://upload-workbench.toolforge.org/ and permanent archive at https://upload-workbench.toolforge.org/v0.33.0/.
Rebased onto current main (v0.31.0) — merge resolved a 3-region conflict in src/table.jsx where T426428's Title-column "Restore from original filename" menu entries landed in the same HeaderMenuPopover prop list / locally-derived consts that T426422 was modifying for the per-language Caption menu entries. The two features are orthogonal in the popover (different columns), so both were taken; npm run build (including the undefined-identifier scanner) is clean against the merge result. CI green, preview verified live.
Merged as v0.32.0 via !49. Live at https://upload-workbench.toolforge.org/ and permanent archive at https://upload-workbench.toolforge.org/v0.32.0/.
Q1 is C
Q2 is A
Q3 !49 is already in main. correct the error made there in the mr
nice! lets move it to the top center of the page and keep it sticky always in sight.
And lets try to enrich the text further with relevant context for trubelshooting bugs or so. and lets ad some inspirational questions fo the user to guide the user to the right a rich and complete bug description of it is about a bug.
Instead of enabling the user to remove the last caption column and just adding a new default caption column at the end, let's just gray out the option with a small text indicating that removing captions entirely is not possible.
@Daanvr — task is groomed (see comment + rewritten description above). Before I implement, three concrete scope decisions only you can make. The cost of guessing wrong on any of these is real refactoring afterwards, so I'd rather pause:
Voice-typed multi-part task. Investigated codebase + external Commons templates; rewriting the description (above) with concrete scope and proposing a sub-MR split. Original preserved here verbatim:
Description rewritten with investigation findings (see task description above). Original preserved here verbatim:
Description rewritten with investigation findings (see task description above). Original preserved here verbatim:
Description rewritten with investigation findings (see task description above). Original preserved here verbatim:
Released v0.31.0 → live at https://upload-workbench.toolforge.org/ (archived at https://upload-workbench.toolforge.org/v0.31.0/).
Addressed feedback on !54:
Addressed feedback on !51:
Addressed feedback on !50:
Addressed feedback on !49: Wikidata-property columns added via the new "+ Add column" popover (or via the Templates-and-columns modal) are now editable.
Addressed feedback on !52:
Released v0.30.0 → live at https://upload-workbench.toolforge.org/ (archived at https://upload-workbench.toolforge.org/v0.30.0/).
Live: https://upload-workbench.toolforge.org/ (also archived at https://upload-workbench.toolforge.org/v0.29.0/).
samll feedback just before merging: the hover tooltip above te "beta" chip is not displaying.
when you repaire this you can merge right away without waiting for review.
Addressed feedback on !55:
awesome!
some small changes:
- when in a MR# the chip next to the title still shows the version number of the last live version.
- the beta indicator should stil exist to the right of the version/mr selector next to the title. it should have a hover tooltip indicating it is a beta, and that many things are not yet working well and that all feedback is verwy welkom!
- clickign the version in the modal should expand and show the changelog and only then the user can jump to the apge of that specific version
no +chip in Captions
when cllicking +chip the suggestion apear under the typing suggestions and such.
the text in the inline chip does reflect the final text expet for the missing spaces.
once a chip is added the text field is not editable as text anymore. my cursor won’t move to before the chips ot add a space or things liek that. only move areoutn in th text after the last chip. clickign on the text befor the chip wil result in unfocus of the cell.
the smal icon with a letter at the start ot the chip is not nessesary. it is not helpful it should be removed.
the resultign text form several chips is sticked together with no spaces or other seperator. that should be a space by default but the suer sould simply be abel to go there with the arrow keys or the mouse cursor to ad something different in between the chips including custom text.
it sould not be possible to remove the last caoption column. also removing a column with values in it should warn the user the values will be removed.
reuploading a file to the stash with pre-existing captions data (in the user namespace metadata) should add the caption columns with existing values.
In short the user should not be able to have caption values linked to a file that is not visible in the table.