Would it be possible to get the same functionality for a footer?

Better yet: Instead of mentioning the PID, link to /daemon/log/.../, it already contains the necessary information (except the UID). There actually is no need for the lengthy list of "expected/actual/started" usernames, which I suggested, if you provide a list of affected daemons with links to their log.

Is this related to T8936? I.e. similar cause?

Alternate style:

A daemon is running as user //observed_username//, while the Phabricator config specifies phd.user to be //expected_username//.

The 3rd paragraph is outright confusing:

phd Daemons will try to use `root` to start as the configured user. Make sure that the user who starts `phd` has the correct sudo permissions to start `root` daemons as `phd`

Section "General Tips" is also affected.

I encountered the same when I tried to write "Amazon S3". I don't think using `backticks` is really appropriate here. Further: How to escape the backticks themselves?

@chad: Thanks for the hints! I had forgotten about the other tasks and they didn't turn up for my search terms.

I consider CC'ing a lightweight first-step towards / alternative to reviews. Thus marking this as a duplicate of T4099.

Comment from T9292: I assumed I could @mention them in the Edit Notes and thus trigger a notification and subscription, which would allow me to point them directly to the changes I made and in addition leave them some information why they receive the notification and what I expect from them. Instead @mentions in the Edit Notes have no effect on the subscriptions/notifications.

The issue is that moving a wiki page leaves around a redirect, which other users can still stumple upon, which is bad from a privacy perspective (since the old content can still be restored from the history). Sadly on our installation some very generic names were choosen, which also collide with new project names.

In Maniphest, maybe "Status: Need Info" and a few canned responses would help?

Idea: Displaying Last-Seen: 5 minutes ago should already help many people and might not require you to track open connections.

What about something basic, like a tooltip? (As suggested above.) I would assume it takes only a few lines of code and should not introduce any support and maintainance nightmares in the future.

In T1139#132636, @lschabel wrote:

Internationalization is very important for non-technical users. I'll contribute a German translation.

I would argue differently ("T8972 is the reason I noticed that conpherence does not allow me to revert mistakes when editing rooms"). If fixing T8972 also allows me to revert the room picture to the original state, then that's fine with me.

My primary concern is the picture. While I can unset the picture of projects, I cannot do so for conferences. Thus there is no way to return to the original state after something like T8972 (or simply a mistake) occurred.

P.S: Since you use transactions everywhere, I assumed they would make the implementation of an undo action rather simple.

Problem: The settings of a Conpherence room were changed mistakenly. I need to undo the change. Resetting Conpherence room images (part of the accidental change) to the default is not possible.

What actually happens is even more annoying: The dialogue displays the values of the previous room, but saving it edits the values of the current room.

Confirmed. Quite annoying, too.

Thanks for the hint with \! From watching some commits, I knew there was such a column, but I didn't figure out how to open it... ;)

One issue might be projects and their member list. Users from other spaces should probably be replaced with a "question mark" placeholder, so that others don't know who it is, but see that the project has some members. That way generic cross-space groups don't become a privacy/security issue.

Wiki page tags would be passed on to pages further down the path. Moving a page to another location would retain the tags and apply any new ones from further up the hierarchy.

In reply to the comments in T3963:

Thanks for the hints and ideas.

Please don't get me wrong. I am doing my best to provide as much helpful feedback as possible, so the product becomes most useful and easy to use in the end.

If macros really shall solve T9153 (updating of links to files):

I understand that the original reporter actually wanted "page templates", not "macros".

@chad So whenever someone wants the same file to be used on multiple wiki pages, they first have to create a page template and then apply that to the other site where they want the file to be linked?

This comes up quite regularly among my users. Even for me it is rather annoying to always have to type full paths - the common case in our (including my) workflow seems to be to link to sub-pages, which becomes unnecessarily cumbersome in Phriction. Additionally this is contrary to experience with well known filesystem functions like symlinks, for example.

In T9165#131879, @epriestley wrote:

There is only one flavor of "Visible To", which is the second, more general one:

Who can see this object and sub-objects / contents?

"Visible To" always means this. If you can point out cases where it doesn't, we'll fix them.

If only someone would read these explanations...

@epriestley: I would also like to tag "internal" users (who are all in one Project), because they also have elevated rights compared to "external collaborators". Or alternatively tag "external users", which in the end has the same effect (T9162).

We recently added external users to our install and have some wiki pages in general locations, which were visible to everyone (and easily reachable / easy to create name clashes). With adding Spaces and adding more external collaborators, we also introduced a new wiki structure (/our_org is where all our internal stuff goes; projects each get /the_project so they can be made accessible to externals if necessary). Thus I had to move a huge bunch of wiki pages (see T6004). Afterwards the old pages were left in a state were their history was still accessible to everyone, which I fixed by destroying them on the commandline. When destroying several dozen of pages, Actions → hover: Flag For Later → right-click → Copy Link Location becomes cumbersome.

@joshuaspence: TBH, I was unable to figure out how it is supposed to work...

Another solution to the mentioned use case would be to automatically put users into Projects (T3980 or external scripts until that is implemented) and then award Badges based on Projects (T9163).

The different behaviours of Visible-To for different types of objects are currently quite confusing to our users.

@swisspol nails it.

Updated to fix a bug where the default $space_phid (and $current_value) would be 'all' instead of $actor->getDefaultSpacePHID().

I updated the patch yet again. In this iteration, anyone can add users to projects, if these users are not in any space at all.

• I could imagine tagging files to order them - that would allow to easily find them later.
• Tagging wiki pages would also be great - e.g. to create a bidirectional link between a project and its wiki pages.
• If a file that was uploaded by dropping it onto a wiki page (as in: drag & drop) would automatically be tagged with the tags of that wiki page, that would solve our problem.

More on the usecases:

Subscribing myself to a Wiki page is already possible. It is also possible to subscribe other people by @mentioning them in the page's content.

Well, if there is a PHP function setlocale() which reliably returns error codes for non-existing locales, then you could simply do something like this:

if (!setlocale(LC_ALL, "en_US.UTF-8") {
  raise_setup_warning(...);
}

• locale -a seems fine. The binary belongs to glibc (libc-bin package on Ubuntu 14.04).
• Editing /etc/locale.gen and then executing locale-gen is the usual way to generate locales. The binary belongs to the locales package on Ubuntu 14.04 and iirc to glibc on Gentoo/Linux.

Alternative: Following patch (for the en_GB.UTF-8 locale).

commit 6d6534ebebe881a85382850c6b9817c9e34571fa
Author: Dennis Schridde <dennis.schridde@uni-heidelberg.de>
Date:   Thu Aug 6 15:00:38 2015 +0200

I added following patch to allow admins to add users into spaces, if currently that user is in no space at all:

I am now using following patch locally:

Would abovementioned approach be viable? I.e. filtering the list of users in /people/, and those which typeahead and similar functions provide? Would you accept a patch that implements it that way? Do you have any other suggestions on how to implement this efficiently?