Ref T6049. This moves Phurl to modular transactions.
Details
Details
- Reviewers
epriestley - Maniphest Tasks
- T6049: Implement Phurl, a URL shortener/bookmarking application
- Commits
- rPd38ee2d79aa6: Update Phurl for modular transactions
Everything works here, add phurl, edit phurl, use phurl. Test various error states. Left a TODO on the validate dupe keys, not sure how to implement that in modular-land.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- phurl-xaction (branched from master)
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 15754 Build 20823: Run Core Tests Build 20822: arc lint + arc unit
Event Timeline
| src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php | ||
|---|---|---|
| 2327 | grep seems to indicate only place used was phurl. ok to move? | |
Comment Actions
validateIsTextFieldTooLong() is good to nuke, but just follow the pattern in DifferentialRevisionTitleTransaction inline instead of moving it. In particular:
- Use getColumnMaximumByteLength() rather than hard-coding a length, so if we change the column later the code will automatically use the correct value.
- strlen(), not phutil_utf8_strlen(), is the best method to use in this case because getColumnMaximumByteLength() is now a strict byte limit.
- No need to check the old value.
| src/applications/phurl/editor/PhabricatorPhurlURLEditor.php | ||
|---|---|---|
| 251–264 | This just stays the same in ModularTransactions, at least for now. There's no real way for us to tell which transaction might be able to handle it. We could maybe just ask each type if it knows what's going on, but I think it will be rare/impossible for third-party code to ever cause duplicate key exceptions to occur that it can't handle directly. | |
| src/applications/phurl/editor/PhabricatorPhurlURLEditor.php | ||
|---|---|---|
| 251–264 | Stays the same? | |
Comment Actions
Just change the PhabricatorPhurlURLTransaction::TYPE_ALIAS constant but leave it where it is otherwise without other changes.