From my experience playing with this and some user feedback:

• Spaces would greatly benefit from having colours and icons. Then not only could the selector show different (and hopefully more obvious) icons, but the header (or site background) colour could also be changed to the colour of the space. A less intrusive coloured line below the header, possibly combined with coloured text in the spaces selector, would also be fine.
• The benefit that this small patch alone does to UX feels immense. Instead of having to adjust spaces for each and every object I create (which actually reduces usability instead of increasing it), I can switch "modes" or "projects" globally, which means a lot if your instance contains objects from very different projects which are being worked on by distinct groups of people.
• User feedback suggests that the position (central header) and combination with a text (space name) improves usability of spaces a lot and makes it very obvious which space one is currently working in.
• Filtering the page contents to show only objects in the currently selected space might help users switching over from Redmine (which is the majority in our case) to understand the concept.

The patch could still need a bit of polishing, but should I already submit a review request anyway, so it becomes easier to discuss necessary changes?

I updated P1834 to fix the mentioned issues:

I've got a patch ready, which basically copies the search scope selector implementation, and is still rather crude and unpolished: P1834

webroot/rsrc/js/core/behavior-spaces-switcher.js:

/**
 * @provides javelin-behavior-phabricator-spaces-switcher
 * @requires javelin-behavior
 *           javelin-typeahead-ondemand-source
 *           javelin-typeahead
 *           javelin-dom
 *           javelin-uri
 *           javelin-util
 *           javelin-stratcom
 *           phabricator-prefab
 */

In T6526#128262, @eadler wrote:

• Another use case: in certain cases badges directly map to projects ("member of admin team" ~= "phacility high command" or "trusted contribute" ~= "trusted contributor" project)

So that makes it $3-6k (according to your Paid Prioritization scheme). Which means we'll have to go with a local patch, unless more funders weigh in.

I gather that you still consider the menu-on-eye-icon the best way to present this UI? Would it help you, if I tried to come up with a patch that does exactly that?

The default language can be changed using following patch (cf. T8916):

diff --git a/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php b/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php
index 72a2252..b233ba0 100644
--- a/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php
+++ b/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php
@@ -72,7 +72,7 @@ final class PhabricatorAccountSettingsPanel extends PhabricatorSettingsPanel {

The default can be changed using following patch (cf. P1821):

Has any progress been made in the last month? Any new decisions on how it should work?

Same happens when I try to push a branch that exists on a different remote:

$ git push origin upstream/hooks
Counting objects: 202, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (127/127), done.
Writing objects: 100% (195/195), 97.63 KiB | 0 bytes/s, done.
Total 195 (delta 64), reused 194 (delta 64)
remote: [2015-07-23 12:20:15] EXCEPTION: (Exception) Unable to identify the reftype of 'refs/remotes/upstream/hooks'. Rejecting push. at [<phabricator>/src/applications/diffusion/engine/DiffusionCommitHookEngine.php:412]
remote: arcanist(head=stable, ref.master=999eb9376568, ref.stable=d54cb072facd), libphremoteuser(head=master, ref.master=1def4e2d7f07), phabricator(head=stable, ref.master=f0bf7a8e2621, ref.stable=2e82fb07cdc1), phutil(head=stable, ref.master=aa6cd8f7e5e5, ref.stable=83f09f6c5a03), sprint(head=production, ref.master=4912ecf41ef1, ref.production=2846fc28ae19)
remote:   #0 DiffusionCommitHookEngine::findGitRefUpdates() called at [<phabricator>/src/applications/diffusion/engine/DiffusionCommitHookEngine.php:220]
remote:   #1 DiffusionCommitHookEngine::findRefUpdates() called at [<phabricator>/src/applications/diffusion/engine/DiffusionCommitHookEngine.php:124]
remote:   #2 DiffusionCommitHookEngine::execute() called at [<phabricator>/scripts/repository/commit_hook.php:133]
To ssh://phab@phab.../diffusion/PV/paraview.git
 ! [remote rejected] upstream/hooks -> upstream/hooks (pre-receive hook declined)
error: failed to push some refs to 'ssh://phab@phab.../diffusion/PV/paraview.git'

But where does "Server Default" come from? Apparently there is a default set somewhere, I just cannot find it…

P.S: After git push has returned, the repository is still in the "Importing" state. So even after 45 minutes there is still some processing left to do?

The visibility of a Space in our Phab instance is using a Custom Policy. When I click the red "Custom Policy" box, I am presented with this text, which does not help me at all:

Users with the "Can View" capability for this object:

P.S: One idea would be to allow admins to select from all (visible) projects when creating a policy, not only those they are a member of.

Also needs following patch to libphutil:

diff --git a/src/internationalization/PhutilTranslator.php b/src/internationalization/PhutilTranslator.php
index b30823b..dfd4706 100644
--- a/src/internationalization/PhutilTranslator.php
+++ b/src/internationalization/PhutilTranslator.php
@@ -136,6 +136,7 @@ final class PhutilTranslator extends Phobject {
       case 'en_W*':
       case 'en_R*':
       case 'en_A*':
+      case 'en_P*':
         list($singular, $plural) = $translations;
         if ($variant == 1) {
           return $singular;

As I see it, rP58fbb0ae532f implements parsing of mailto://. However this is, as you already mentioned, rather useless, because clicking the link will not allow to send an email (in KMail, it opens a new-mail window with an empty To: field). Is it possible to reconsider fixing this in a way that actually works?

See-Also: https://github.com/facebook/hhvm/issues/5505

@epriestley: I understand your concerns about supporting custom scripts, but what do you think about creating initialised user profiles? Currently it seems that loadUserProfile() just dumps something with a PHID on you (when the profile did not yet exist), which is not actually a valid object. The fix seems trivial.

In T8549#120808, @chad wrote:

The colors are the same as the "bar color" that currently exists. We added an icon and tooltip for more information and flexibility. This will allow better flexibility in apps like Maniphest, where you could use the icon to covey different states instead of just "open" and "closed".

Next one: In S2, click Space Test Users (the policy at the top, right next to "Active"). You see a dialogue with the text:

Users with the "Can View" capability:

My first question: What do the colours of the exclamation marks in front of the tasks mean? i see purble, blue, orange, but neither the tooltip, nor any other part of the list item gives any hint regarding their meaning.

It seems indeed that the profile created by $user->loadUserProfile() is broken or incomplete.

I agree with @20after4: We would also like to insert our organisation's logo instead of the "eye". Replacing the text alone feels insufficient.

The users I tried this with all do not have a user profile set in the database. Thus I assume Phabricator tries to create blank profiles, when it applies the changes to the CustomFields, which then fails to be inserted, since these do not comply with the database schema?

It is already possible to invite and subscribe projects. Ain't that even better than just tagging?

I would like to use this to keep my users updated about recent changes of our Phabricator instance.

P.S: Destination was the conpherence room icon / image drag&drop field, not the message entry area.

I posted this primarily, because there are some division by zero errors logged. I guess those could be fixed by improved error handling.

@btrahan - works now, thanks!

@dpaola2: Your issue should have been fixed just recently.

Just ran into this. Apache logs the following (/var/log/php5-fpm.log contains nothing about this incident…?):

Seems to work here: rHGTEST0e1f30ecdecaf66a3da45a62b7c6af3ad7c5515a

Confirmed: Fixed

auto-scrolling to bottom of a thread not working all that well

See-Also: https://phabricator.wikimedia.org/T493

See-Also: https://phabricator.wikimedia.org/T493

The issue is conduit.deprecated.user.addstatus, which is impossible to fix. I do not want to ignore it either, because I want to monitor the problem for several more days until I am sure that really nothing uses that call anymore.

It appears what you show in your screenshot is present, but hidden behind the "Phabricator" logo: Screenshot

Click "Search" in the left menu from within Conpherence, at the top.

I am unable to find a way to create or join new rooms, or edit existing ones. After I created my first room, it seems the UI to do it is simply gone. How can I access it?

In T7717#104737, @hach-que wrote:

For some strange reason, it has now disappeared after creating a room...

We would also need to sync Projects with LDAP groups, as we need most groups also in other applications outside of Phabricator. If payment helps, I can ask my boss about it.

I would also need to remove all linked authentications and the email address (and potentially SSH keys, etc), since I will have to reuse both. And in my case the user is already destroyed, so there is no way back anymore.

The same issue happens when you try to add a new user to a thread containing a user that was destroyed. The destroyed user shows up in the list as Unknown Object (User) and I receive the same Validation errors: - New thread member "PHID-USER-…" is not a valid user. message.

In T7692#104265, @epriestley wrote:

In some setups, your patch allows any attacker to log in to any LDAP account by just not typing a password.

In my authentication module I have e.g. this code for my PhutilAuthAdapter:

public function getAccountRealName() {
  $username = explode("@", $this->getAccountID(), 2)[0];
  $provider = PhabricatorLDAPAuthProvider::getLDAPProvider();

P.S: Setting the session expiry time to 1h as you suggest is very inconvenient in my case. What I actually need is a "normal" expiry time, but using a session cookie on the client. So he gets automatically logged out when he closes the browser, but can use the session as long as necessary if he does not.

@epriestley You asked for reasons for automatic session expiry. Several users of mine expect that their session expires when they close their browser. I think this is the default for many sites: If one wants to login permanently, one has to take specific action to enable it (often a "remember me" checkbox). If one uses a shared computer, the difference between expected and actual behaviour could become a problem.

Thanks, works!

Thanks, works!

This is not caused by adblockers (µBlock in my case), and reloading the page does not fix it either.

I cannot attach files here (drag and drop does not work, maybe because the container Firefox is running in misses some bit), but I uploaded it to imgur: Screenshot

My exact usecase:

• I use authentication via libphremoteuser (REMOTE_USER envvar)
• For registration, I want to display the proper real-name and email address
• I need to fetch that from LDAP
• I can conveniently do that (with a small patch) using the PhabricatorLDAPAuthProvider

It's pushed to the origin remote, but not my upstream remote. I.e. I have been working on this internally, but now I want to officially submit it. For two reasons: (1) It needs review first (2) I do not have write access to the upstream repository.

Oh, I thought because the functionality exists for dashboards, it also exists for apps. Thanks for clarifying that.

Ok. I hope my feedback helps you somehow to improve the Calendar after prototype.

I would say my report classifies as a Use Case, in addition to indicating General Interest…