I think it starts out as a URL, and then replaced on the client-side with the name after some AJAX. Most of the time I don't have time to see the "before" text.

I don't understand why it's a tag. Does the JIRA link look like a URL or an actual name?

css is it's own world of magick.

I'm faking my way through it.

Here's Chrome's Style page for the element:

I'm just surprised to hear something is still overflowing after D16081.

DoorkeeperTagView is also used for DifferentialAsanaRepresentationField, which is probably easier to set up (?).

The value is rendered here: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/differential/customfield/DifferentialJIRAIssuesField.php;70463e8a16d4cbe0c83b23b9328c4a359072c506$53

I'd need to see it to fix it. These are tags?

Alright, thanks for clearing it up, and sorry for calling it a bug :) I am new to phabricator, trying to see if I can configure it for my needs where permissions have a big role. Maybe I should explain what I am trying to do, so my request maybe makes more sense. You are of course welcome to close this task as wontfix, I just, as a new user, found it confusing that the edit policy wasn't strictly enforced around the application, view policy seems more strict though, which is nice :)

I have a somewhat similar problem when I try to start a working copy job:

There are many situations where you can make an edit in one way but not in another. For example, you can't edit the subscribers for a task via "Edit Task" on the detail page, workboards, or task list, or via the API, or via mail commands but you can edit them via "Subscribe", "Unsubscribe", with Herald, by commenting with @username, or via the action dropdown.

Thanks for the quick reply.

This is expected. You do not need "edit" permission to comment on a task, subscribe to it, award it tokens, or take other actions available in the action dropdown.

I have no plans to support that in the upstream. Running commands on the Phabricator host is a very unusual use case, and it would allow anyone who can write a Herald rule to write one that runs rm -rf / or compromises the Phabricator install by reading session keys out of MySQL.

Hi Evan!

Assume you are testing. Please use http://phacility.com if you want to try Phabricator at no cost. This is a working installation.

See D10391

@witrin Thanks for that contribution! I really need this.
I tried to set this up but I got the followeing error:

Additionally, you should use maniphest.edit, not maniphest.update.

Also, for clarification, "Administrators" on Phabricator are just regular users as far as policies go. They don't override them.

Closing for lack of feedback. If you're able to update your install and provide this task with a set of reproducible steps, we can look into it further.

This issue is not always reproducible but happens very frequently:

Updating Phabricator is required before submitting a bug report.

Yeah, I think you can just do a SQL migration like:

User enters full URI (protocol + domain + optional port), like https://blog.phacility.com/ (UI is basically the same as it is now -- they still enter one value, it just has protocol + port now).

In T9640#172158, @chad wrote:

I'll fire up a VM this weekend and see if there are any issues.

I've applied the patch and updated by URI accordingly (removed the ssh config as well) - seems to work

So what exactly do you need to comment out for this to work on PHP7? Is is src/applications/cache/spec/PhabricatorDataCacheSpec.php and src/applications/cache/spec/PhabricatorOpcodeCacheSpec.php

Yes, put the port in the URI like a normal URI (host.com:1234).

I'm willing to give it a go, just to confirm before I do that what my URI would be in the UI?

svn+ssh://svn.host.name:port/srv/repo/url/path/

If you have time, can you let me know if this patch fixes things?

I think the root of this is largely building a commit mapping from "draft" commits to their equivalent "published" commits. I believe all of the approaches available to us are:

I'm just going to merge this into T5953. The LDAP importer is a contributed patch from yesteryear which we wouldn't bring upstream today, and unlikely to see improvements outside of a more formal upstream effort in T5953.

git blame suggests that this hasn't ever matched on word boundaries (it didn't in August 2012, when it was first written -- see rPHU45f7bd6a).

I can't reproduce this on the linked install or locally either; presuming we fixed it at some point.

We haven't seen other users encounter difficulty with this, and the error message is relatively specific already.

This is sort of resolved since Diffusion moved to PHUITwoColumnView and project tags are now listed in the sidebar, labeled "Tags", while VCS tags are listed in the main list, also labeled "Tags". Labeling them both "tags" isn't great, but context provides some help and this doesn't immediately appear to be particularly confusing.

When we destroy an object, we load all its edges and destroy them too.

This install now exposes two separate actions in a new submenu, although the backend is only sort of halfway converted. My plan is:

Thank you Evan for your ansewer!

The repository created last year.

I am running Phabricator up to date (I upgrade it today, using git pull --rebase)

Edge Constant 39 was TYPE_OBJECT_USES_CREDENTIAL, which was removed a few months back.

What are the steps to reproduce the error, specifically? I can't trigger this exception.

Sorry for the disruption.

Should probably be fixed once D16170 is deployed...

Here's what I'm thinking here:

• Add lint/unit/coverage "summary" field to each Build.
• Recalculate whenever new lint/unit objects show up (Possibly offline via daemon).
• arc-side lint/unit already generates a Build, so this one will hold the --nolint/--nounit information (+ excuse?)
• Anywhere we currently show that information, load the summary information and aggregate that, instead of aggregating all lints/units directly.