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>
      281f22c2
  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
      Summary:
      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
      4adaf53b
  4. 17 Jun, 2015 1 commit
    • epriestley's avatar
      Cache viewer spaces · 984976ce
      epriestley authored
      Summary:
      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
      984976ce
  5. 11 Jun, 2015 2 commits
    • epriestley's avatar
      Support Spaces in ApplicationEmail · 0bc8382d
      epriestley authored
      Summary:
      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
      0bc8382d
    • epriestley's avatar
      Allow Spaces to be archived · 88e7cd15
      epriestley authored
      Summary:
      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
      88e7cd15
  6. 10 Jun, 2015 1 commit
    • epriestley's avatar
      Improve some Spaces behaviors · 739bdecc
      epriestley authored
      Summary:
      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
      739bdecc
  7. 05 Jun, 2015 3 commits
    • epriestley's avatar
      Put Spaces on Hovercards and ObjectItemLists · 1e4e1219
      epriestley authored
      Summary: Ref T8449.
      
      Test Plan:
      {F474186}
      
      {F474187}
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: chad, epriestley
      
      Maniphest Tasks: T8449
      
      Differential Revision: https://secure.phabricator.com/D13173
      1e4e1219
    • 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:
      {F473836}
      
      {F473837}
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: epriestley
      
      Maniphest Tasks: T8441
      
      Differential Revision: https://secure.phabricator.com/D13171
      b5dfd34e
    • epriestley's avatar
      Provide core policy support for Spaces · c1c897b9
      epriestley authored
      Summary:
      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
      c1c897b9
  8. 01 Jun, 2015 2 commits
  9. 20 Apr, 2015 1 commit
    • epriestley's avatar
      Make buildWhereClause() a method of AphrontCursorPagedPolicyAwareQuery · f5580c7a
      epriestley authored
      Summary:
      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
      f5580c7a
  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 `192.168.0.1`, 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
      3e704f6c
  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
      86c399b6
  12. 22 Oct, 2013 2 commits
    • epriestley's avatar
      Harbormaster v(-2) · b5a00933
      epriestley authored
      Summary:
      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
      b5a00933
    • epriestley's avatar
      Lock policy queries to their applications · 2a5c987c
      epriestley authored
      Summary:
      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
      2a5c987c
  13. 22 Jul, 2013 1 commit
    • epriestley's avatar
      Use application PHIDs for mailing lists · c5a06a62
      epriestley authored
      Summary:
      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
      c5a06a62
  14. 01 Jul, 2013 1 commit
    • epriestley's avatar
      Add DifferentialDiffQuery and change most callsites · 90123dd7
      epriestley authored
      Summary:
      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
      90123dd7
  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
      Summary:
      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
      fc9ad37b
  21. 05 Nov, 2012 1 commit
    • vrana's avatar
      Delete license headers from files · ef85f49a
      vrana authored
      Summary:
      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
      ef85f49a
  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
      1154447d
  23. 23 Oct, 2012 1 commit
    • epriestley's avatar
      Allow policy-aware queries to prefilter results · 51c4b199
      epriestley authored
      Summary:
      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
      51c4b199
  24. 13 Sep, 2012 1 commit
    • epriestley's avatar
      Allow projects to be set as policies · a1df1f2b
      epriestley authored
      Summary:
        - 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
      a1df1f2b
  25. 07 Aug, 2012 1 commit
    • epriestley's avatar
      Rename "IDPaged" to "CursorPaged", "executeWithPager" to "executeWith[Cursor|Offset]Pager" · ed4a155c
      epriestley authored
      Summary:
      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
      ed4a155c
  26. 02 Jun, 2012 1 commit
    • epriestley's avatar
      Make chatlog a bit less awful · 6a8ac915
      epriestley authored
      Summary:
        - 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
      6a8ac915
  27. 01 Jun, 2012 1 commit
    • vrana's avatar
      Move files in Phabricator one level up · 6cc196a2
      vrana authored
      Summary:
      - `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:
      /D1234
      Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general.
      
      Auditors: epriestley
      
      Maniphest Tasks: T1103
      6cc196a2
  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
      e696619d
  30. 17 Feb, 2012 1 commit
    • epriestley's avatar
      Add a basic chatlog · 72000404
      epriestley authored
      Summary:
      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
      72000404