followup to D8544. This ends up creating an editor + transactions to get the job done.
Details
Details
- Reviewers
epriestley - Commits
- Restricted Diffusion Commit
rP655ac9927fa4: Workboards - add column detail page
made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- coldetails
- Lint
Lint Passed - Unit
Tests Passed
Event Timeline
| src/applications/project/storage/PhabricatorProjectColumnTransaction.php | ||
|---|---|---|
| 8 | think we should have a TYPE_TASK and log a transcation for tasks leaving / entering? This seemed somewhat useful to me
Seemed outside scope of this diff so I held it. Candidate for next diff or next next diff if you think we should do it. | |
Comment Actions
Nice!
I think TYPE_TASK might be useful, but those specific use cases don't seem super amazing to me (but I'm not sure I fully understand the error case -- I think that's mitigated by more filtering options for the board down the road, though?). One thing I'd worry about is that this page might get 900000 pages long and require that we build history paging/etc., although that's obviously not too hard.
Maybe hold it for now and we'll put it in the next^5 diff or something if it's more clearly useful?
| src/applications/project/storage/PhabricatorProjectColumn.php | ||
|---|---|---|
| 19 | Hmm, I would expect us to still need this when, e.g., viewing a project board for the first time so it implicitly creates the "Default" column, at a minimum? | |
Comment Actions
un-remove setName('') call for default case; upgrade $old === null to !strlen($old) to handle new default in transaction code.