1. 29 Mar, 2020 1 commit
    • Daniel Stone's avatar
      LOCAL: Make 'All Users' space extremely magic · 281f22c2
      Daniel Stone authored
      Phriction's view policy is ancestral: in order to access /w/foo/bar/baz,
      you must be able to access /w/foo and /w/bar in addition to
      /w/foo/bar/baz itself.
      This is fine and makes life easy: by setting restrictive policies on
      top-level pages, we can lessen the risk of someone exposing information
      they shouldn't, by accidentally making
      /w/cold-fusion/secret-research/funding-meeting/2018-09-14 public, when
      the rest of the hierarchy is super locked down.
      Phriction also recently gained Spaces support, which is nice: rather
      than trying to lock down with groups and harmonise permissions, we can
      just move top-level wiki pages to a particular Space, and then we don't
      need to worry about groups.
      Our clients don't know Spaces even exist, which is great since it avoids
      us having to explain the two-tier permission model to them. The reason
      they don't know it exists is because if you can only see a single Space,
      then Phabricator hides the entire Spaces UI away from you. Great!
      Unfortunately one detail ruins everything: /w/ is a top-level page
      itself, it counts for permission checks, and it _must be in a Space_.
      So, there is no way to have wiki documents in mutually-invisible Spaces
      unless you also have a common Space, at which point the whole Spaces UI
      suddenly becomes very visible everywhere.
      In order to try to keep our wiki partitioned, but to not confuse our
      clients (and give them the chance to potentially expose confidential
      information!), we:
        - have a magic 'Visible to Everyone' space
        - actually hide that space from everyone with policies
        - hack policy filters to make this space visible to everyone _only
          for the purpose of checking policies on wiki objects_
        - only allow admins to change view/edit policies on the root wiki
          page (see comment for reason why)
      This actual patch can obviously never go anywhere near upstream, but on
      the other hand we should probably make them aware of the problem and see
      if they're interested in discussing a solution, which is probably just
      to bless the root page with magic semantics.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
  2. 23 Feb, 2016 1 commit
  3. 30 Jun, 2015 1 commit
    • epriestley's avatar
      Dramatically increase cache hit rate for feed · 4adaf53b
      epriestley authored
      Ref T8631. The query plan for feed stories is really bad right now, because we miss caches we should be hitting:
        - The workspace cache is stored at each query, so adjacent queries can't benefit from the cache (only subqueries). Feed has primarily sibling queries.
          - There is no technical reason to do this. Store the workspace cache on the root query, so sibling queries can hit it.
        - In `ObjectQuery`, we check the workspace once, then load all the PHIDs. When the PHIDs are a mixture of transactions and objects, we always miss the workspace and load the objects twice.
          - Instead, check the workspace after loading each type of object.
        - `HandleQuery` does not set itself as the parent query for `ObjectQuery`, so handles never hit the workspace cache.
          - Pass it, so they can hit the workspace cache.
        - Feed's weird `PhabricatorFeedStory::loadAllFromRows()` method does not specify a parent query on its object/handle queries.
          - Just declare the object query to be the "root" query until this eventually gets cleaned up.
      Test Plan: Saw queries for each object drop from 4-6x to 1x in `/feed/`.
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T8631
      Differential Revision: https://secure.phabricator.com/D13479
  4. 17 Jun, 2015 1 commit
    • epriestley's avatar
      Cache viewer spaces · 984976ce
      epriestley authored
      Ref T8575. Although we cache spaces as a whole, we don't cache viewer spaces. This can still do a lot of work if they have complex policies.
      Instead, cache them in the request cache.
      Test Plan: Saw this account for 37% of a page in produciton (303ms on on 835ms).
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T8575
      Differential Revision: https://secure.phabricator.com/D13324
  5. 11 Jun, 2015 2 commits
    • epriestley's avatar
      Support Spaces in ApplicationEmail · 0bc8382d
      epriestley authored
      Ref T8498. Allow ApplicationEmail addresses to be put into spaces:
        - You can only see and send to addresses in Spaces you have access to.
        - Objects are created into the same space their address is associated with.
      Test Plan:
        - Used `bin/mail receive-test` to send mail to various `xyz-bugs@...` addresses.
        - Saw objects created in the proper space.
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T8498
      Differential Revision: https://secure.phabricator.com/D13247
    • epriestley's avatar
      Allow Spaces to be archived · 88e7cd15
      epriestley authored
      Ref T8377. This adds a standard disable/enable feature to Spaces, with a couple of twists:
        - You can't create new stuff in an archived space, and you can't move stuff into an archived space.
        - We don't show results from an archived space by default in ApplicationSearch queries. You can still find these objects if you explicitly search for "Spaces: <the archived space>".
      So this is a "put it in a box in the attic" sort of operation, but that seems fairly nice/reasonable.
      Test Plan:
        - Archived and activated spaces.
        - Used ApplicationSearch, which omitted archived objects by default but allowed searches for them, specifically, to succeed.
        - Tried to create objects into an archived space (this is not allowed).
        - Edited objects in an archived space (this is OK).
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T8377
      Differential Revision: https://secure.phabricator.com/D13238
  6. 10 Jun, 2015 1 commit
    • epriestley's avatar
      Improve some Spaces behaviors · 739bdecc
      epriestley authored
      Ref T8449. Try out some more subtle behaviors:
        - Make the "Space" control part of the policy control, so the UI shows "Visible To: [Space][Policy]". I think this helps make the role of spaces more clear. It also makes them easier to implement.
        - Don't show the default space in headers: instead, show nothing.
        - If the user has access to only one space, pretend spaces don't exist (no edit controls, no header stuff).
      This might be confusing, but I think most of the time it will all align fairly well with user expectation.
      Test Plan:
        - Viewed a list of pastes (saw Space with non-default space, no space with default space, no space with user in only one space).
        - Viewed a paste (saw Space with non-default space, saw no space with default space, saw no space with user in only one space).
        - Edited spaces on objects (control as privileged user, no control as locked user).
        - Created a new paste in a space (got space select as privileged user, no select as locked user).
      Reviewers: chad, btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T8449
      Differential Revision: https://secure.phabricator.com/D13229
  7. 05 Jun, 2015 3 commits
    • epriestley's avatar
      Put Spaces on Hovercards and ObjectItemLists · 1e4e1219
      epriestley authored
      Summary: Ref T8449.
      Test Plan:
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: chad, epriestley
      Maniphest Tasks: T8449
      Differential Revision: https://secure.phabricator.com/D13173
    • epriestley's avatar
      Support PhabricatorSpacesInterface in ApplicationSearch UI · b5dfd34e
      epriestley authored
      Summary: Ref T8441. Does what it says, provided other conditions (like using the new SearchField stuff) are fulfilled.
      Test Plan:
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T8441
      Differential Revision: https://secure.phabricator.com/D13171
    • epriestley's avatar
      Provide core policy support for Spaces · c1c897b9
      epriestley authored
      Ref T8424. No UI or interesting behavior yet, but integrates Spaces checks:
        - `PolicyFilter` now checks Spaces.
        - `PolicyAwareQuery` now automatically adds Spaces constraints.
      There's one interesting design decision here: **spaces are stronger than automatic capabilities**. That means that you can't see a task in a space you don't have permission to access, //even if you are the owner//.
      I //think// this is desirable. Particularly, we need to do this in order to exclude objects at the query level, which potentially makes policy filtering for spaces hugely more efficient. I also like Spaces being very strong, conceptually.
      It's possible that we might want to change this; this would reduce our access to optimizations but might be a little friendlier or make more sense to users later on.
      For now, at least, I'm pursuing the more aggressive line. If we stick with this, we probably need to make some additional UI affordances (e.g., show when an owner can't see a task).
      This also means that you get a hard 404 instead of a policy exception when you try to access something in a space you can't see. I'd slightly prefer to show you a policy exception instead, but think this is generally a reasonable tradeoff to get the high-performance filtering at the Query layer.
      Test Plan:
        - Added and executed unit tests.
        - Put objects in spaces and viewed them with multiple users.
        - Made the default space visible/invisible, viewed objects.
        - Checked the services panel and saw `spacePHID` constraints.
        - Verified that this adds only one query to each page.
      Reviewers: btrahan, chad
      Reviewed By: btrahan
      Subscribers: chad, epriestley
      Maniphest Tasks: T8424
      Differential Revision: https://secure.phabricator.com/D13156
  8. 01 Jun, 2015 2 commits
  9. 20 Apr, 2015 1 commit
    • epriestley's avatar
      Make buildWhereClause() a method of AphrontCursorPagedPolicyAwareQuery · f5580c7a
      epriestley authored
      Ref T4100. Ref T5595.
      To support a unified "Projects:" query across all applications, a future diff is going to add a set of "Edge Logic" capabilities to `PolicyAwareQuery` which write the required SELECT, JOIN, WHERE, HAVING and GROUP clauses for you.
      With the addition of "Edge Logic", we'll have three systems which may need to build components of query claues: ordering/paging, customfields/applicationsearch, and edge logic.
      For most clauses, queries don't currently call into the parent explicitly to get default components. I want to move more query construction logic up the class tree so it can be shared.
      For most methods, this isn't a problem, but many subclasses define a `buildWhereClause()`. Make all such definitions protected and consistent.
      This causes no behavioral changes.
      Test Plan: Ran `arc unit --everything`, which does a pretty through job of verifying this statically.
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: yelirekim, hach-que, epriestley
      Maniphest Tasks: T4100, T5595
      Differential Revision: https://secure.phabricator.com/D12453
  10. 17 Oct, 2014 1 commit
    • epriestley's avatar
      Build AlmanacNetwork · 3e704f6c
      epriestley authored
      Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at ``, we'll know it's on some specific NAT block or whatever.
      Test Plan: See screenshots.
      Reviewers: btrahan
      Reviewed By: btrahan
      Subscribers: epriestley
      Maniphest Tasks: T5833
      Differential Revision: https://secure.phabricator.com/D10715
  11. 23 Jul, 2014 1 commit
    • Joshua Spence's avatar
      Rename `PhabricatorApplication` subclasses · 86c399b6
      Joshua Spence authored
      Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`.
      Test Plan:
      # Pinned and uninstalled some applications.
      # Applied patch and performed migrations.
      # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled.
      # Performed a sanity check on the database contents.
      Reviewers: btrahan, epriestley, #blessed_reviewers
      Reviewed By: epriestley, #blessed_reviewers
      Subscribers: hach-que, epriestley, Korvin
      Maniphest Tasks: T5655
      Differential Revision: https://secure.phabricator.com/D9982
  12. 22 Oct, 2013 2 commits
    • epriestley's avatar
      Harbormaster v(-2) · b5a00933
      epriestley authored
      Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together:
        - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc.
        - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically.
        - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists.
        - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them.
        - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit.
        - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues.
        - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems.
        - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages.
        - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence.
      This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are:
        1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me.
        2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall.
      The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs.
      Test Plan: Poked around, but this doesn't really do anything yet.
      Reviewers: btrahan
      Reviewed By: btrahan
      CC: zeeg, chad, aran, seporaitis
      Maniphest Tasks: T1049
      Differential Revision: https://secure.phabricator.com/D7368
    • epriestley's avatar
      Lock policy queries to their applications · 2a5c987c
      epriestley authored
      While we mostly have reasonable effective object accessibility when you lock a user out of an application, it's primarily enforced at the controller level. Users can still, e.g., load the handles of objects they can't actually see. Instead, lock the queries to the applications so that you can, e.g., never load a revision if you don't have access to Differential.
      This has several parts:
        - For PolicyAware queries, provide an application class name method.
        - If the query specifies a class name and the user doesn't have permission to use it, fail the entire query unconditionally.
        - For handles, simplify query construction and count all the PHIDs as "restricted" so we get a UI full of "restricted" instead of "unknown" handles.
      Test Plan:
        - Added a unit test to verify I got all the class names right.
        - Browsed around, logged in/out as a normal user with public policies on and off.
        - Browsed around, logged in/out as a restricted user with public policies on and off. With restrictions, saw all traces of restricted apps removed or restricted.
      Reviewers: btrahan
      Reviewed By: btrahan
      CC: aran
      Differential Revision: https://secure.phabricator.com/D7367
  13. 22 Jul, 2013 1 commit
    • epriestley's avatar
      Use application PHIDs for mailing lists · c5a06a62
      epriestley authored
      Ref T2715. Ref T603. Ref T2625.
        - Implement policies.
        - Use policy queries.
        - Use ApplicationSearch.
        - Use application PHIDs.
      Test Plan: Browsed things with lists CC'd; edited lists; created a list, used `phid.query` to query handles.
      Reviewers: btrahan
      Reviewed By: btrahan
      CC: aran
      Maniphest Tasks: T603, T2625, T2715
      Differential Revision: https://secure.phabricator.com/D6513
  14. 01 Jul, 2013 1 commit
    • epriestley's avatar
      Add DifferentialDiffQuery and change most callsites · 90123dd7
      epriestley authored
      Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites.
      I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites.
      Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls.
      Reviewers: btrahan
      Reviewed By: btrahan
      CC: aran
      Maniphest Tasks: T603
      Differential Revision: https://secure.phabricator.com/D6338
  15. 31 May, 2013 2 commits
  16. 07 Mar, 2013 1 commit
  17. 20 Dec, 2012 1 commit
  18. 19 Dec, 2012 1 commit
  19. 05 Dec, 2012 1 commit
  20. 22 Nov, 2012 1 commit
    • epriestley's avatar
      Add very basic scaffolding for Pholio · fc9ad37b
      epriestley authored
      I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
      Basic hierarchy is:
        - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
        - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
        - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
        - **PixelComment**: Equivalent of an inline comment.
      Test Plan: Created a fake object and viewed it.
      Reviewers: btrahan, chad
      Reviewed By: btrahan
      CC: aran, davidreuss
      Maniphest Tasks: T2097
      Differential Revision: https://secure.phabricator.com/D3817
  21. 05 Nov, 2012 1 commit
    • vrana's avatar
      Delete license headers from files · ef85f49a
      vrana authored
      This commit doesn't change license of any file. It just makes the license implicit (inherited from LICENSE file in the root directory).
      We are removing the headers for these reasons:
      - It wastes space in editors, less code is visible in editor upon opening a file.
      - It brings noise to diff of the first change of any file every year.
      - It confuses Git file copy detection when creating small files.
      - We don't have an explicit license header in other files (JS, CSS, images, documentation).
      - Using license header in every file is not obligatory: http://www.apache.org/dev/apply-license.html#new.
      This change is approved by Alma Chao (Lead Open Source and IP Counsel at Facebook).
      Test Plan: Verified that the license survived only in LICENSE file and that it didn't modify externals.
      Reviewers: epriestley, davidrecordon
      Reviewed By: epriestley
      CC: aran, Korvin
      Maniphest Tasks: T2035
      Differential Revision: https://secure.phabricator.com/D3886
  22. 31 Oct, 2012 1 commit
    • epriestley's avatar
      Add PhabricatorFileQuery · 1154447d
      epriestley authored
      Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness.
      Test Plan: Will use in Pholio.
      Reviewers: btrahan, vrana
      Reviewed By: btrahan
      CC: aran
      Differential Revision: https://secure.phabricator.com/D3829
  23. 23 Oct, 2012 1 commit
    • epriestley's avatar
      Allow policy-aware queries to prefilter results · 51c4b199
      epriestley authored
      Provides a simple way for policy-aware queries to pre-filter results without needing to maintain separate cursors, and fixes a bunch of filter-related edge cases.
        - For reverse-paged cursor queries, we previously reversed each individual set of results. If the final result set is built out of multiple pages, it's in the wrong order overall, with each page in the correct order in sequence. Instead, reverse everything at the end. This also simplifies construction of queries.
        - `AphrontCursorPagerView` would always render a "<< First" link when paging backward, even if we were on the first page of results.
        - Add a filtering hook to let queries perform in-application pre-policy filtering as simply as possible (i.e., without maintaing their own cursors over the result sets).
      Test Plan: Made feed randomly prefilter half the results, and paged forward and backward. Observed correct result ordering, pagination, and next/previous links.
      Reviewers: btrahan, vrana
      Reviewed By: btrahan
      CC: aran
      Differential Revision: https://secure.phabricator.com/D3787
  24. 13 Sep, 2012 1 commit
    • epriestley's avatar
      Allow projects to be set as policies · a1df1f2b
      epriestley authored
        - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings).
        - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X").
        - Introduces `PhabricatorPolicy`, which describes a policy.
        - Allows projects to be set as policies.
        - Allows Paste policies to be edited.
        - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan.
      Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc.
      Reviewers: vrana, btrahan
      Reviewed By: vrana
      CC: aran
      Maniphest Tasks: T603
      Differential Revision: https://secure.phabricator.com/D3476
  25. 07 Aug, 2012 1 commit
    • epriestley's avatar
      Rename "IDPaged" to "CursorPaged", "executeWithPager" to "executeWith[Cursor|Offset]Pager" · ed4a155c
      epriestley authored
      I'm trying to make progress on the policy/visibility stuff since it's a blocker for Wikimedia.
      First, I want to improve Projects so they can serve as policy groups (e.g., an object can have a visibility policy like "Visible to: members of project 'security'"). However, doing this without breaking anything or snowballing into a bigger change is a bit awkward because Projects are name-ordered and we have a Conduit API which does offset paging. Rather than breaking or rewriting this stuff, I want to just continue offset paging them for now.
      So I'm going to make PhabricatorPolicyQuery extend PhabricatorOffsetPagedQuery, but can't currently since the `executeWithPager` methods would clash. These methods do different things anyway and are probably better with different names.
      This also generally improves the names of these classes, since cursors are not necessarily IDs (in the feed case, they're "chronlogicalKeys", for example). I did leave some of the interals as "ID" since calling them "Cursor"s (e.g., `setAfterCursor()`) seemed a little wrong -- it should maybe be `setAfterCursorPosition()`. These APIs have very limited use and can easily be made more consistent later.
      Test Plan: Browsed around various affected tools; any issues here should throw/fail in a loud/obvious way.
      Reviewers: vrana, btrahan
      Reviewed By: vrana
      CC: aran
      Maniphest Tasks: T603
      Differential Revision: https://secure.phabricator.com/D3177
  26. 02 Jun, 2012 1 commit
    • epriestley's avatar
      Make chatlog a bit less awful · 6a8ac915
      epriestley authored
        - Default to showing the newest page of chat.
        - Reformat for greater readability.
        - Add permalinks to specific lines.
        - Enable jump-to-date.
      Test Plan: {F12200}
      Reviewers: Koolvin, vrana, btrahan
      Reviewed By: btrahan
      CC: kdeggelman, aran
      Maniphest Tasks: T837, T1065
      Differential Revision: https://secure.phabricator.com/D2641
  27. 01 Jun, 2012 1 commit
    • vrana's avatar
      Move files in Phabricator one level up · 6cc196a2
      vrana authored
      - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`.
      - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php`
      - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`.
      NOTE: `arc diff` timed out so I'm pushing it without review.
      Test Plan:
      Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general.
      Auditors: epriestley
      Maniphest Tasks: T1103
  28. 05 Apr, 2012 1 commit
  29. 27 Mar, 2012 1 commit
    • Bob Trahan's avatar
      Chatlog - add a pager · e696619d
      Bob Trahan authored
      Summary: 'cuz I miss out on chat room goodness and can't paginate around in the current version
      Test Plan: setup a phabot and spammed it in phabot-test. with new test data, set $page_limit = 1 and paged about -- looks good!
      Reviewers: epriestley
      Reviewed By: epriestley
      CC: aran, epriestley
      Maniphest Tasks: T990
      Differential Revision: https://secure.phabricator.com/D2032
  30. 17 Feb, 2012 1 commit
    • epriestley's avatar
      Add a basic chatlog · 72000404
      epriestley authored
      This is pretty simple and unpolished, but it's getting pretty big and it seems
      like a reasonable starting point.
        - Log chat in various "channels".
        - Conduit record and query methods.
        - IRCBot integration for IRC logging
      Major TODO:
        - Web UI is really unpolished and has no search, paging, anchor-linking, etc.
      Basically all presentation stuff, though.
        - I think the bot should have a map of channels to log with channel aliases?
        - The "channels" should probably be in a separate table.
        - The "authors" should probably be correlated to Phabricator accounts somehow,
      where possible.
      Test Plan: Used phabotlocal to log #phabricator.
      Reviewers: kdeggelman, btrahan, Koolvin
      Reviewed By: btrahan
      CC: aran, epriestley
      Maniphest Tasks: T837
      Differential Revision: https://secure.phabricator.com/D1625