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.

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}

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...

Thanks! :)

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.

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).

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.

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

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.

yep you were right. just missed a case.

I should add that the current setup check only alerts if there's a mismatch between config and running daemon.
If phd.user is not configured at all (default) it will not trigger.

Attached diff allows for batch edits of all tasks in a workboard column (only all, no selection possible). And please note that you have to reload the board when you make column moves and want to batch edit afterwards!
Very handy to close all tasks in a column or add/remove a project.

One way of doing this is by adjusting the mapping for the elasticsearch index (actually way more powerful than a wildcard search).
I currently switched to the mapping below (added as a template expecting the index to be named 'phabricator' and with an english language setting).
Feel free to change the min/max ngrams setting (e.g. 4 instead of 3 letter ngrams) if you get too many / few results.
If you like to switch to another language the docs to do so are here: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/analysis-lang-analyzer.html
For it to take effect you have to delete the index and then reindex all objects (bin/index --all).

My dev env is up2date.
But you're right that all the tasks are assigned to one user and that causes the problem within loadStatus on every page.
However as far as i can see in the reports the getDestinationPHIDs is called for every user there is and therefore causes the same problem there.
I've rearranged the way getDestinationPHIDs works a bit and it went from 60s to a 2s load time (for loadStatus as well). Which is still not great but might be acceptable for a reports page or a user who has 10k assigned tasks.

Ok, i've created ~10k tasks in my dev installation to test this more thoroughly.
I still see the full table scan on the edge table (tested on mysql 5.1 & 5.6). E.g.:

If the reports feature is what the user expects to find or is helpful is a whole different question.

The attached revision will get all tasks marked as duplicate in the maniphest db and then tries to find the task it was merged into in the elasticsearch just using the title.
By default it will use the standard analyzed field in elasticsearch as it is right now.
If you run installmapping and reindex the tasks the results should get better because it will utilize english stopwords and stemming.
Let's see what this yields. If it still find too less results we can try to combine an ngrams / edge_ngrams analyzer into it.

In ManiphestTaskQuery it says:

// TODO: Eventually, we should make this optional and introduce a
// needProjectPHIDs() method, but for now there's a lot of code which
// assumes the data is always populated.

We have the same problem with more casual submitters.
I could think of a fairly easy but powerful implementation of this when elasticsearch as a backend is used.
The custom scoring and basic language processing stuff is really nice and would allow for things like listing bugs within the same project before others quite easily.

We had a similar problem (tracking feature branches and triggering a herald rule when a commit shows up in master) and solved it by specifically looking for the merge commit in the master/production branch.
Depending on what your herald rule does it might be necessary to apply an action to every commit contained in a merge commit. I'm not sure what happens if you trigger an audit on the merge commit. It might include more commits than what you want.

there seems to be some major changes between the mysql versions with the charsets and the syntax.
When running the adjust script against a mysql 5.1 i get:
#1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'binary NULL' at line 1

as mentioned this is a dev install just for me. i'd be happy to test with a mysql 5.1 if you like. doesen't matter if it completely breaks ;)

Ah i see. I thought the changes were already merged. My dev installation i've made earlier today still has utf8_general_ci.

Upon importing the phabricator repo the import will stop at 99% because the last commit containing the unicode char can't be imported.
Error is the same that initially triggered the whole problem:

I've just set up a new dev phabricator today using a mysql 5.1.41
Error logs are flooded with (for every query): ERROR 2: mysqli::set_charset(): Error executing query at [.....libphutil/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:70]

Had some free time today and implemented this. The improvement however is not as big as i expected.
Doing a blame on phabricators __phutil_library_map__.php will take ~20sec without and ~15sec with the cache on my dev vm.

D10586 implements the "arc feature T123". It will assign the task if it's free and tell you who owns it otherwise. (Creating the branch in both cases)