1. 29 Mar, 2020 1 commit
    • Daniel Stone's avatar
      Accept arrays in PHID custom-field validation · 20dd5a7a
      Daniel Stone authored
      As setValueFromStorage() notes, we can accept either JSON strings or arrays for PHID-type custom fields. Handle this in decodeValue by passing through an array if we've received one.
      
      Test Plan:
        - Add Maniphest custom field with PhabricatorPeopleDatasource
        - Create task with field filled
        - Go to Maniphest task detail view
        - Observe no errors in DarkConsole / PHP error log
      20dd5a7a
  2. 11 Feb, 2016 1 commit
    • epriestley's avatar
      Add "does not match regexp" to Herald · 8934dee5
      epriestley authored
      Summary:
      Fixes T10330.
      
        - Anywhere we support "matches regexp", also allow "does not match regexp". Although you can sometimes write a clever negative regexp, these rules are better expressed with "does not match <simple regexp>" anyway, and sometimes no regexp will work.
        - Always allow "does not contain" when we support "contains".
        - Fix some JS issues with certain rules affecting custom fields.
      
      Test Plan:
        - Wrote an "Affected files do not match regexp" rule that required every diff to touch "MANUALCHANGELOG.md".
        - Tried to diff without the file; rejected.
        - Tried to diff with the file; accepted.
        - Wrote a bunch of "contains" and "does not contain" rules against text fields and custom fields, then edited tasks to trigger/observe them.
        - Swapped the editor into custom text, user, remarkup, etc fields, no more JS errors.
      
      {F1105172}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10330
      
      Differential Revision: https://secure.phabricator.com/D15254
      8934dee5
  3. 24 Dec, 2015 1 commit
    • epriestley's avatar
      Show hovercards for most links in object property views · 3ec07c49
      epriestley authored
      Summary:
      Ref T8980. This isn't 100% coverage but should be pretty much all of the common ones.
      
      These feel a touch iffy to me at first glance so I didn't go crazy trying to hunt all of them down. I have some other plans for them so maybe they'll feel better by the end of it.
      
      Test Plan: Hovered over author, reviewers, blocked tasks, projects, etc.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T8980
      
      Differential Revision: https://secure.phabricator.com/D14877
      3ec07c49
  4. 09 Dec, 2015 1 commit
  5. 02 Dec, 2015 1 commit
    • epriestley's avatar
      Support HTTP parameter prefilling in EditEngine forms for CustomFields · c1ae5321
      epriestley authored
      Summary:
      Ref T9132. This allows you to prefill custom fields with `?custom.x.y=value`, for most types of custom fields.
      
      Dates (which are substantially more complicated) aren't supported. I'll just do those once the dust settles. Other types should work, I think.
      
      Test Plan:
        - Verified custom fields appear on "HTTP Parameters" help UI.
        - Used `?x=y` to prefill custom fields on edit form.
        - Performed various normal edits.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9132
      
      Differential Revision: https://secure.phabricator.com/D14634
      c1ae5321
  6. 02 Nov, 2015 1 commit
  7. 13 Oct, 2015 1 commit
    • epriestley's avatar
      Allow "Repository Automation" to be configured for repositories · df5a031b
      epriestley authored
      Summary:
      Ref T182. This allows you to assign blueprints that a repository can use to perform working copy operations. Eventually, this will support "merge this" in Differential, etc.
      
      This is just UI for now, with no material effects.
      
      Most of this diff is just taking logic that was in the existing "Blueprints" CustomField and putting it in more general places so Diffusion (which does not use CustomFields) can also access it.
      
      Test Plan:
        - Configured repository automation for a repository.
        - Removed repository automation for a repository.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Subscribers: avivey
      
      Maniphest Tasks: T182
      
      Differential Revision: https://secure.phabricator.com/D14259
      df5a031b
  8. 10 Oct, 2015 1 commit
    • epriestley's avatar
      Rough cut of "Blueprint Authorizations" · 2f6d3119
      epriestley authored
      Summary:
      Ref T9519. This is like 80% of the way there and doesn't fully work yet, but roughly shows the shape of things to come. Here's how it works:
      
      First, there's a new custom field type for blueprints which works like a normal typeahead but has some extra logic. It's implemented this way to make it easy to add to Blueprints in Drydock and Build Plans in Harbormaster. Here, I've added a "Use Blueprints" field to the "WorkingCopy" blueprint, so you can control which hosts the working copies are permitted to allocate on:
      
      {F869865}
      
      This control has a bit of custom rendering logic. Instead of rendering a normal list of PHIDs, it renders an annotated list with icons:
      
      {F869866}
      
      These icons show whether the blueprint on the other size of the authorization has approved this object. Once you have a green checkmark, you're good to go.
      
      On the blueprint side, things look like this:
      
      {F869867}
      
      This table shows all the objects which have asked for access to this blueprint. In this case it's showing that one object is approved to use the blueprint since I already approved it, but by default new requests come in here as "Authorization Requested" and someone has to go approve them.
      
      You approve them from within the authorization detail screen:
      
      {F869868}
      
      You can use the "Approve" or "Decline" buttons to allow or prevent use of the blueprint.
      
      This doesn't actually do anything yet -- objects don't need to be authorized in order to use blueprints quite yet. That will come in the next diff, I just wanted to get the UI in reasonable shape first.
      
      The authorization also has a second piece of state, which is whether the request from the object is active or inactive. We use this to keep track of the authorization if the blueprint is (maybe temporarily) deleted.
      
      For example, you might have a Build Plan that uses Blueprints A and B. For a couple days, you only want to use A, so you remove B from the "Use Blueprints: ..." field. Later, you can add B back and it will connect to its old authorization again, so you don't need to go re-approve things (and if you're declined, you stay declined instead of being able to request authorization over and over again). This should make working with authorizations a little easier and less labor intensive.
      
      Stuff not in this diff:
      
        - Actually preventing any allocations (next diff).
        - Probably should have transactions for approve/decline, at least, at some point, so there's a log of who did approvals and when.
        - Maybe should have a more clear/loud error state when no blueprints are approved?
        - Should probably restrict the typeahead to specific blueprint types.
      
      Test Plan:
        - Added the field.
        - Typed some stuff into it.
        - Saw the UI update properly.
        - Approved an authorization.
        - Declined an authorization.
        - Saw active authorizations on a blueprint page.
        - Didn't see any inactive authroizations there.
        - Clicked "View All Authorizations", saw all authorizations.
      
      Reviewers: chad, hach-que
      
      Reviewed By: chad
      
      Maniphest Tasks: T9519
      
      Differential Revision: https://secure.phabricator.com/D14251
      2f6d3119
  9. 29 Sep, 2015 2 commits
    • epriestley's avatar
      Simplify value decoding for PHID custom fields · efaa8170
      epriestley authored
      Summary:
      Ref T9123. The handling in D14183 didn't deal with new field values properly.
      
      Make all this handling more consistent.
      
      Test Plan: Created a new WorkignCopy build plan with some repos.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9123
      
      Differential Revision: https://secure.phabricator.com/D14184
      efaa8170
    • epriestley's avatar
      Allow Harbormaster build plans to request additional working copies · bfaa93aa
      epriestley authored
      Summary:
      Ref T9123. To run upstream builds in Harbormaster/Drydock, we need to be able to check out `libphutil`, `arcanist` and `phabricator` next to one another.
      
      This adds an "Also Clone: ..." field to Harbormaster working copy build steps so I can type all three repos into it and get a proper clone with everything we need.
      
      This is somewhat upstream-centric and a bit narrow, but I don't think it's totally unreasonable, and most of the underlying stuff is relatively general.
      
      This adds some more typechecking and improves data/type handling for custom fields, too. In particular, it prevents users from entering an invalid/restricted value in a field (for example, you can't "Also Clone" a repository you don't have permission to see).
      
      Test Plan: Restarted build, got a Drydock resource with multiple repositories in it.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9123
      
      Differential Revision: https://secure.phabricator.com/D14183
      bfaa93aa
  10. 25 Sep, 2015 1 commit
  11. 17 Jul, 2015 1 commit
  12. 06 Jul, 2015 1 commit
  13. 07 Jun, 2015 1 commit
  14. 05 May, 2015 1 commit
  15. 04 Apr, 2014 1 commit
  16. 25 Mar, 2014 1 commit
  17. 26 Feb, 2014 1 commit
  18. 21 Feb, 2014 1 commit
    • epriestley's avatar
      Implement "Repository" as a new-style CustomField in Differential · 01572d9d
      epriestley authored
      Summary:
      Ref T3886. Ref T418.
      
        - Adds new capabilities for CustomField:
          - Controls can now bulk-load PHIDs (e.g., for tokenizers).
          - Transactions can now bulk-load PHIDs (e.g., for relationship changes).
        - Implements "Repository" control.
        - Improves tokenizer StandardCustomField controls.
      
      Test Plan:
      {F115942}
      
      {F115943}
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      CC: aran
      
      Maniphest Tasks: T418, T3886
      
      Differential Revision: https://secure.phabricator.com/D8286
      01572d9d
  19. 16 Sep, 2013 1 commit
    • epriestley's avatar
      Add "user" and "users" standard custom fields · ed7a5078
      epriestley authored
      Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that.
      
      Test Plan: See screenshots.
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      CC: aran
      
      Differential Revision: https://secure.phabricator.com/D7010
      ed7a5078