The other thing that's probably worth mentioning is that when I tried to create a new repo on the updated install, it has the same problems. Running the failing command in the repository root also succeeds, so it seems to be a paths thing... although the '.git' at the end of the command freaks me out, because the repos are bare, so there is no .git folder.

With the results being the same either way. The previous install was @ 6a035d977f22aaf1 (I will admit this was a bit lazy.. that's from November of last year).

Can you describe a specific case where a generator emits some equivalent substring and can not be modified to emit a different substring? See Describing Root Problems.

What did you do, specifically? Backup -> Move -> Update -> Test?

In T9348#156836, @joshuaspence wrote:

In T9348#156791, @exp10r3r wrote:

I tried doing an arc diff to submit my patch but ran into this,

[2016-02-02 21:15:55] EXCEPTION: (PhutilTypeExtraParametersException) Got unexpected parameters: standard at [<phutil>/src/parser/PhutilTypeSpec.php:150]
arcanist(), phabricator(head=master, ref.master=3264d9f680cb), phutil()
  #0 PhutilTypeSpec::checkMap(array, array) called at [<arcanist>/src/lint/engine/ArcanistConfigurationDrivenLintEngine.php:90]
  #1 ArcanistConfigurationDrivenLintEngine::buildLinters() called at [<arcanist>/src/workflow/ArcanistLintersWorkflow.php:44]
  #2 ArcanistLintersWorkflow::run() called at [<arcanist>/scripts/arcanist.php:382]

I could run through it by removing the following section in .arclint file,

,
    "xhpast": {
      "type": "xhpast",
      "include": "(\\.php$)"
    }

But it wouldn't let me commit.

Update Arcanist

Thanks.

I think the settings thing got fixed, and we're probably (?) going to move away from widgets in the next iteration.

At least so far, this doesn't seem like an acute problem. I'm going to close it until we have specific feedback.

I'm just going to close this out for now, we'll clean up any remaining crud in the next iteration.

I think the script was removed around the time AphrontSite was written, because it was using a pretty hacky approach to figure out the right controller. You can now find the current controller in DarkConsole → Request → Controller:

After recent upgrade I no longer have this ./scripts/aphront/aphrontpath.php file. Was it moved to different place?

Thanks for the quick fix !

We had (and have) the notification server up&running.
Notifications are working in general, but not reliably for chat messages.

That fix isn't retroactive, but I'll deploy it here now so future slowvotes benefit.

In T10349#159385, @epriestley wrote:

@kislinsk In cases like the one you describe (which I consider reasonable), what's your major concern with naming the subproject "ABC (Core)" to resolve the ambiguity of a task tagged with both "ABC > Core" and "XYZ > Core"?

(I generally agree that we probably do need more default or optional disambiguation here, but want to make sure we're making the best tradeoffs we can as we move forward.)

I think you should be good to go at HEAD now, let me know if I missed anything.

I suspect its a mixture of history and expectations since Phabricator is used solely as a review system and not as a primary communication mechanism.

OH HA HA HA NO YOU CAN'T

(apologies if this recently changed, I'm a few weeks behind master)

Yeah, "Department A > Team Members" or "Department A > Other people who should have edit access even though they are not formally members of any subproject" both seem like reasonable approaches to that issue to me.

I think the external thing should be able to set policies correctly today, although maybe I'm misremembering something.

Just to clarify on your last question: I wanted to be able to do "Members of: Department A". I guess my idea of putting the members on a random subproject is the way to go for this (and I think that's what you are suggesting). Also, it's not strictly a matter of security, we use it for visibility purposes too (like when a user opens "Projects" we'd rather show them those that are relevant to their department by default and have him manually search for others).

Yeah, we have some packages which are generated by another application, and some which are generated by users, I wanted to lock the field only when the package was generated by the other application, this is a simplified version of the actual extension in place.

Alright. Some general thoughts, not sure if any of this is helpful:

Currently, no block elements (lists, tables, code blocks, interpreter blocks, etc) work inside table cells. They interpret their content as inline only. So this is the expected behavior.

It's mostly a control thing, I can't think of any real world dangers. Eventually we plan on having even more limited access groups (for external users, similar to this installation) where there would definitely be a concern, but that may not have anything to do with this task.