Excellent, thanks for explaining!

Ah, I was probably getting confused by that: so as I now understand, the superproject membership inherits from the subprojects it contains?

That's expected.

See T10003. See T9905 for broader discussion. See the Changelog to find information about changes before you perform an upgrade.

Also, adding / removing members from superproject

Also, adding / removing members from superproject / subproject isn't working.

When you make a task in a subproject, clicking on the project name in the task detail view will give you a 404 as it tries to access /tag// (as there is no project tag set on sub projects)

Yes, they are getting error message as shown below,

You can just leave a comment here.

What happens when they try?

Yes, there was some changes in map.php and I reverted to 14ae3c099c2e4ce6c706bbaa4aa9fcb4bc7d3dec. Now the issue is fixed. But no one other than Administrator can able to create new task.

I know this is all prototype at this stage, but where's the best place to highlight bugs with the current implementation? Should I just file a bug report in maniphest?

Ah, thanks. I think it's just missing a disabled state -- I wouldn't expect the edit to actually go through when you save (or are you seeing the edit work, too?).

6081e640b154631cfc36b4d554a75638201762cd is not a commit in the upstream. Do you have local patches?

Locking the icon field in projects doesn't actually work, it's still possible to edit the icon when that field is locked.

If you're using ElasticSearch on your install, can you let us know why you're choosing to configure it over the builtin MySQL search?

FWIW, at the WMF we make releases that involve hundreds of repositories: one for mediawiki, plus one for each mediawiki extension that we host. I don't think it is an ideal situation, and it causes me all kinds of grief, but it's the current state of affairs. So there is at least one potential use case for a release that encompasses a snapshot of multiple repos.

This is intentional.

There's nothing particularly actionable remaining here, although we'll always have more things to cache.

No, you can not reorganize existing projects.

Question: I saw your screenshots at rP7c5ad63fd1d613a62727624ec31436d7933b0bbd

The worst case scenario was not real, but some time ago I was admin at a instance with public registration. We disabled the possibilty to let users adjust the task policys, after two users abused this to hide important tasks from developers. Sure, we restored this tasks by bin/policy, but we had first to find out, which numbers the tasks had, so we had to insert time in a problem, that can be easily fixed. After this, we disabled the ability to change tasks poliycs for unstrusted users. The problem now, is, that if new users have tasks with confidential informations, they need to contact us at another way, which means more work too, but makes existing tasks more secure. My proposal above has the advantage, that they can report confidetal data, if they change the space, but they had no change to hide data from us, and mass abuse can reverted by a bulk edit.

I would say that would be an intriguing feature request.

@chad thanks for the clarification, I indeed mangled these authentication tokens with the Tokens application.

I previously linked you to Support Resources. Please read that document.

I need some help with Phabricator . What should I do ?

This does not describe a bug with Phabricator. See Contributing Bug Reports and Support Resources.

dfsdf

Fair enough I guess, and you are right. It's just a reality check when you see your personal e-mail address pop up in a Google search... :/

Actually, even GitHub exposes unrecognized email addresses directly in the page source, which is the same behavior we have:

Is this an actual problem you've experienced, or purely hypothetical?

Has that actually happened? Our expectation is non experienced users who don't need certain fields should just use a custom form.

I don't think this represents a real problem. This information is inherently public: pushing commits to a public repository makes this information public and easily retrievable by automated means.

I think the problem "People can hide tasks from admins and staffs, and you need to investigate much work to find this tasks, and at a worst case scenario people can do illegal thinks at that task, which is not visible for you" is a root problem, because you can't control all tasks at a public instance without forbid the people to mark tasks as not public visible. So you can't give people a chance to report security issues, or issues/requests with private data. This is an existing problem. For example Wikimedia wrote a 3rd party extension for this problem, which lets herald change the policys, without let people adjust the policys at their own (they can choose at a dropdown). So the problem exists, and it can easily solved, by the proposed solution.

This feature request doesn't describe a problem, see Describing Root Problems. Specifically, "feature doesn't exist or might cause an issue" doesn't give us any indication how people are having issues using Phabricator.

Guess I'll report this to them

Oh wait, I see now that the issue is in a plugin I have installed

I still think the original request is the best solution. Creating save states or visibility filters sounds overly complicated. Why would you not want users to be able to delete columns (other than the axiom that you don't let users delete anything)?

I also might take a crack at fixing "human language diffs", I think I can get something which is worlds better than what we do right now pretty quickly (even if it isn't perfect) and it would be nice to be able to be smarter all over the place about communicating description/title changes and tailoring things for typo fixes, spelling mistakes and other minor edits. I think this is something we can get groundwork in place for and then improve gradually without needing to do any big rewrites or anything.

Yeah I wanted to patch that this weekend but haven't gotten to it. :(

The logic around what we send to blog subscribers is a little goofy right now, and sends them the entire post content on every update.

Thanks, fixed.

Broken link for Customizing Forms documentation. Should be to https://secure.phabricator.com/book/phabricator/article/forms/