you can add libreoffice/soffice to your list. last time we had to do sth like this we used soffice --headless --convert-to pdf
not really better than running a browser though... in our use case we needed to use merchant uploaded doc/docx templates in combination with our data. so even less options.
but yeah most options around pdf generation are clunky.

We've been experiencing this problem from time to time as well.
In our case between two Phabricator installations.
The internal one observing a repository from a central dev server which always works fine.
Then the internal phabricator has a "mirror" URI configured for the repository to push any changes to an external phabricator installation.
This mirroring fails from time to time with the same error others have posted before (Unable to identify the reftype of 'refs/remotes/... in src/applications/diffusion/engine/DiffusionCommitHookEngine.php:404). Sometimes i could fix it by simply deleting a remote branch that was no longer needed anyway.
I've added a dirty fix now by inserting a "continue;" at line 404 so that the parser in findGitRefUpdates() simply skips unknown ref types and still imports the changes instead of failing completely with an exception.
Though i'm not sure what kind of side effects i might have introduced with this.

I tested the patch on my install and it restores the old behaviour!

Unfortunately i'm not quite sure from exactly which version we've upgraded from. But you're probably right and it was a version before Aug 17.
I regularly read the release logs and in the ones i checked before upgrading (which was about 2-3 months worth of em) the latest Modernisation seemed the only thing touching something related to the problem.
D16413 probably didn't make it into any changelog or was just such a minor note that i didn't see it.

I think this might have broken one of our Herald rules. The rule in question is an Object rule for Commits on a Project and will open an Audit whenever a commit is made to a repository that's tagged with this project.
At least it did ~2 month ago and after the upgrade it just won't fire. Just using the test console on a new commit in a repo tagged with the project simply says "Rule failed".
To make sure i already removed all the other conditions from it so it only states "always".

The whole "identify the packager problem" with composer is indeed a big one and i'm not suggesting you use composer in any way for the arcanist/phabricator packages! Generally i agree that i want to primarily trust the packager and not the developer. This is the way this is handled with os packages (rpm/deb) and companies are used to the workflow: Getting new packages from a somewhat trusted/signed source (e.g. redhat/canonical), testing them yourself, signing them with your own key as well and then distributing to the internal repositories and "end users" only trust your own internal key.

It might be beneficial to generally support gpg signed commits / tags in phabricators git repos and then use the same mechanism for the arcanist packages.
Since github recently started pushing this feature a bit (https://github.com/blog/2144-gpg-signature-verification) quite a few library maintainers started signing their release tags.
And i just recently spoke to a lib maintainer about extending composer to verify all packages (on install or upgrade) against a list of authors trusted by the user (or an enterprise wide list).

I've run into this problem with my puppet repositories. A common puppet workflow is to use every branch as a puppet environment.
This way you can test a large change on a subset of production servers before applying it to the production branch itself.

Sure :)
I remember that the biggest performance gain was coming from using PHIDs when selecting all the commit info in the FileController instead of the commit identifiers.
Showing the blame info on the library_map file was a good benchmark.

Ok, i misunderstood the withMemberPHIDs reference. I thought you wanted to get all the members of a parent project including it's childs.

Have you considered using a nested set for the project hierarchies and build them dynamically?
I've used it in the past for hierarchy stuff and it performs very well for things like "get the sum of value X from this Entity and all of it's children"

I think sth like the following would be quite common:

Sales
     -> Milestone 1
     -> Milestone 2
Engineering 
      -> Backend Team
            -> Sprint 1
            -> Sprint 2
      -> Security Team
            -> Milestone 1
            -> Milestone 2

Regarding the two use cases Engineering -> Backend && TeamX -> Sprint2:
I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).
All that's needed would be some magic upon project creation that uses the members from another project as a template (the last sprint or maybe the parent project as default).

@d.maznekov Here's my (working) config for an ActiveDirectory:
Hostname: IP of the DC
Port: 389
Base distinguished name: dc=company,dc=net
Search attributes: sAMAccountName
anonymous username: ldap
anonymous password: ***
username attribute: sAMAccountName
realname attribute: displayName
LDAP version: 3
No Referrals
No TLS
ActiveDirectoryDomain: DOM (domain name in short form)

Maybe take a look @ D10600: Implement a git blame cache

The more gradual implementation is probably best. This diff spiralled a bit out of control.
However i'd still vote for the separate Editor / Publisher classes just for the sake of read/maintainability.
The automatic state save/load to transfer it to the workers feels quite dirty.

Most phabricator object cannot be deleted through the webui; only archived/disabled.
You can use the phabricator/bin/remove utility to remove most of them permanently if you want to.
I'm not sure if it works for build plans already though...

Nice :)

Elasticsearch mapping is part of head now. So the rest is quite obsolete.

This needs a major rebase.
Let me know when/if you are interested to move on this and if you think refactoring the stuff into workers is the right approach.

I think you need to use updateTransactionMailBody instead of buildApplicationTransactionMailBody.

Thanks! :)

• fix inlines

• add diffusion.fields config and disable mergedcommits by default & celerity map fix

attached revision adds the feature as a customfield to diffusion (like branches & tags). However diffusion has no diffusion.fields config yet so currently i can't disable it by default.
Additional configurability for the customfields would be nice but would in this case only allow to set the max no. of commits shown.

rebase

rebase and fix visibility

rebase

just wasn't sure if there was a bette place to actually call setURI/Index.

just use a constructor

Attached diff would be a quick fix. Probably not the right place to put it though. There seems to be no good place to actually call the new setURI/setIndex

Didn't look at the code yet but it seems like the offset is somehow counted double (try playing with the offset parameter). Decreasing/Increasing it by one will add/remove two results each.
To get the remaining 14 tasks you can do a offset=50 (which will skip the first 100 tasks).

I remember having to do something else for this to work. Unfortunately i can't remember what :(
The feature works fine for me.

Yep. try setting both.

There are config settings for this already. Take a look at metamta.diffusion.inline-patches (which sets the maximum patch length inlined).

Feels good on iOS too.
Thanks guys

This feels very broken on mobile/iOS.
Not only am i unable to fast scroll to the bottom (fast swipe down won't work, it will always scroll just a little bit) it will also randomly stop scrolling down as if there was no more content. I was only able to comment on this commit by clicking on the last file and scrolling down a little bit. Simply scrolling over the diff to the bottom didn't work.(got stuck somewhere during the first file and wouldn't let me scroll down further)

rebase

rebasing

rebasing

I agree for the typical developer use-case. But currently people reporting bugs/suggesting features use maniphest as well and for them the email notification is crucial. So always sending them is probably best for now.

I like the idea, but i think it's a tricky thing to get right. On most sites that do this i always had occasional problems not getting email notifications when opening/closing the site repeatedly during the day (which also is a common thing for me with tools like pahbricator).
I think notifying a user via email if he doesen't act on a web notification in a certain amount of time would be best. But that might make it way more tricky to implement.

Ah ok. I see.
Guess it's not worth fixing this then.

I guess if needed the links would then be just handled by the conpherence controller.
If not just showing a "deprecated" message would be nice.

rebasing

• just remove some lint warnings. makes the diff easier to read

• further refactoring. adding feeds to workers and a lot of cleanup.
• provide a migration path for the other applications

• add new db schema config
• populate blame cache on reparse
• replaced some code with an already existing conduit call
• rebasing and fix db validity issues
• reabsing

I think the object herald rule would be reasonable. I can also imagine a use-case like the 'cowboy commits' rule on this install, bur where i don't wanna go as far as triggering an audit for every commit. Or grouping commits to project by the files touched for example.
Using project inheritance from the repo automatically would probably be wrong in a lot of cases.

I suppose what he's trying to achieve is to see all commits related to a project in the projects feed. (we spoke in irc)
And in some cases this might be all commits made to a specific branch.

Did you upgrade phabricator and maybe forgot libphutil ?
This function was renamed on 05.01.15 by 15e0669609d3f2a24d4212b69c02990ea19c510d

Basically i've just moved some code around. (I've just added comments to the old stuff so you can see where it comes from)

move check into reply handler where phids are already expanded

Ok yeah you're right. The expansion happens later. it actually happens twice. In the MailReplyHandler and in the MetaMTAMail class again - removing the expansion in the replyhandler seems to have no noticable effect. i still get emails if i'm just a project member.
Sending the email in the right locale would be very messy to resolve right now and i think your idea in T6367 (moving the whole rendering of emails for transactions into a worker) is the right choice. I'll take a look at this in more detail tomorrow.
Fixing the permissions problem for now could go into the ReplyHandler as it already knows about the object it is sending email about. So adding a policy check there should be easy.
I'll attach a diff.

The maniphest.status config option allows you to specify any status as being treated as "closed".
Actually there is no single "closed" status. But resolved, invalid, spite & wontfix are all treated as closed.
Feel free to rename / change this properties to your liking and your preferred workflow.
What you describe would be somethink like:

{
  "open": {
    "name": "Open",
    "special": "default"
  },
  "resolved": {
    "name": "Resolved",
    "name.full": "Resolved",
    "closed": false,
    "prefixes": [
      "fix",
      "fixes",
      "fixed",
      "resolve",
      "resolves",
      "resolved"
    ],
    "suffixes": [
      "as resolved",
      "as fixed"
    ]
  },
  "closeresolved": {
    "name": "Resolved & Closed",
    "name.full": "Closed, Resolved",
    "closed": true,
    "special": "closed",
    "prefixes": [
      "closed",
      "closes",
      "close"
    ]
  },
  "wontfix": {
    "name": "Wontfix",
    "name.full": "Closed, Wontfix",
    "closed": true,
    "prefixes": [
      "wontfix",
      "wontfixes",
      "wontfixed"
    ],
    "suffixes": [
      "as wontfix"
    ]
  },
  "invalid": {
    "name": "Invalid",
    "name.full": "Closed, Invalid",
    "closed": true,
    "prefixes": [
      "invalidate",
      "invalidates",
      "invalidated"
    ],
    "suffixes": [
      "as invalid"
    ]
  },
  "duplicate": {
    "name": "Duplicate",
    "name.full": "Closed, Duplicate",
    "transaction.icon": "fa-times",
    "special": "duplicate",
    "closed": true
  },
  "spite": {
    "name": "Spite",
    "name.full": "Closed, Spite",
    "name.action": "Spited",
    "transaction.icon": "fa-thumbs-o-down",
    "silly": true,
    "closed": true,
    "prefixes": [
      "spite",
      "spites",
      "spited"
    ],
    "suffixes": [
      "out of spite",
      "as spite"
    ]
  }
}

just run

./bin/search init

first.
This will create the needed elasticsearch index.

Just some personal experience with ws vs. wss:
In our websites we've noticed that a few Anti-Virus programs which tend to proxy http sessions (e.g. Kaspersky) are unable to do the websocket upgrade.
Sometimes the HTTP polling fallback (don't know if you use something like that) works, sometimes it'll break completely.

I've reproduced it locally and this fixes it. Before the patch these were two separate foreaches.

Ref T6849

Thanks for tracking this down!

• enforce order of markup rules by setting priority (now works as expected)
• initialize identifierMap only once loadPage() instead of willFilterPage()
• %Ld instead of %Ls

simplify maniphest transaction fix

rPHUba927e22f98477e8a8aed28459391dd8ff512ae0
rPHUba927
rPHU:ba927e22f98477e8a8aed28459391dd8ff512ae0
rPHU:ba927
R2:ba927e22f98477e8a8aed28459391dd8ff512ae0
R2:ba927
R2
rPHU

now only allow R123 R123:commit rTEST rTEST:1234
lowercase r for callsigns and uppercase for IDs