I'm going to get this to being able to build a real file, and hand it over unless you think the rest is trivial. Not sure how this would need to work in the NUX case. Generate an image when PhabricatorUser is triggered? What about old defaults?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 28 2017
crc32 would be fine in this use case too since the requirements are so lax. My version isn't particularly robust either, but should get the job done.
Works great!
This actually seems a little difficult to fix...maybe just make it truncate with an ellipsis?
heh nice. And I didn't even have to cheat by using U+00A0.
Oh is crc32 bad?
diff --git a/src/infrastructure/util/PhabricatorHash.php b/src/infrastructure/util/PhabricatorHash.php index 00d7cca63c..5dfbbe2617 100644 --- a/src/infrastructure/util/PhabricatorHash.php +++ b/src/infrastructure/util/PhabricatorHash.php @@ -78,6 +78,22 @@ final class PhabricatorHash extends Phobject { return $result; }
Actually, may have found something on "the google". bbs
Since I'm not a real programmer, getting stuck on how to assign something by username. I presume we want every chad to get the same pre-built avatar if possible. I could just randomize it, but that seems not really beneficial.
Feb 27 2017
Yeah, that's a reasonable starting point. I'm sure noone has 99+ task edit forms..... ⛈
And the pencil icon on workboards, the pencil icon on the list view, and the "Edit Task" action from task detail pages would default to "Edit Plant Task", yeah. The workboard change would only pertain to creating new tasks directly on a workboard.
Right now, this menu always says "Create Task..."
For now, we either don't change workboards or just put all the global options into the menu, probably?
Calling this resolved since the page is now tolerably bad (~5s) which more or less pulls this out of the realm of critical scaling issues.
I added the panel back as an option. I'll leave this open until we see if anyone else hits a similar case.
Feed shows stuff that is happening to items with a certain tag. We want to list the items themselves, not what is happening to them.
Instead of Feed?
I like that, sounds like a very good compromise.
Yes, we were using the panel to show all items (tasks, revisions, wiki pages, et cetera) tagged with a certain tag.
- If the date is a day or more in the future, show days + hours + minutes.
- If the date is an hour or more in the future, show hours + minutes + seconds.
- Otherwise, show minutes + seconds with THRILLING TENTHS OF A SECOND.
Ok, first part is checked in and seems reasonable. https://secure.phabricator.com/uiexample/view/PhabricatorFilesComposeAvatarExample/
This does not describe a bug in Phabricator. I've reviewed the documentation and believe it is already sufficiently clear in describing how to accomplish what you're trying to accomplish. Particularly, I don't see anything in the documentation which is misleading, or suggests that the workflow you're using is the correct way to accomplish your goal -- it isn't, and the documentation describes the correct workflow. See Support Resources for other support resources.
(They could also go into the existing "Waiting on Review" bucket, but I dislike mixing authored and non-authored revisions in that bucket.)
The actual reproduction instructions are slightly more involved:
I can make a fix so this doesn't fail and grandfather these in if they were in use, but I'd also like to know if people are using these as panels, so I can revert that change if needed.
Is that a panel you were using?
Reading through the diff you mention (D17341 I think?) I see that the query type was probably called "Fulltext Results". Basically the query panel version of this page: https://secure.phabricator.com/search/query/advanced/
For wikimedia's "scap" tool we built a feature called "checks" which are configurable commands that run on each target machine and confirm if the desired commands were successful.
Specifically, "Wiki Documents" and "Legalpad Documents" both still are available, but "Documentation Atoms" from Diviner are not.
Can you clarify the steps to reproduce please? I don't know what "Documents" query type is, even reading through the diff that restricted useless panel types.
This is something I've wished for a few times. Along with just searching for repositories in general.
@jmeador, I believe this is now resolved at HEAD. Let us know if you're still seeing issues after upgrading?
After D17422, I used bin/lipsum to generate about 20,000 badges. (They all have USERS permission so the permission checks are about as fast as possible.)
After implementing PHP7 support for XHProf and updating Lipsum, I used bin/lipsum to generate 4,000 packages owning 150,000 paths. I think I have an approximately-reasonable reproduction case locally now, which generates this profile (6.5s for a change affecting about 100 files):
I did the last deploy (T12316) with Phage again and things went much more smoothly after the various bugfixes and improvements.
See Planning for information on timelines and priorities.
I'm using phabricator to do continuously integeration. I need to judge which branch is updated when jenkins receives the http request.
The funny thing is that event if I remove the file from Files, the coverage image in the Maniphest is still there. :)
@jmeador I tried your suggested configuration. The system works, but the server/config/cluster/notifications/ gives the following error instead:
Feb 26 2017
I have a build of this that technically works now (produces profiles, passes tests, does not segfault when gently poked). It's still extremely really rough so I don't know when I'll clean it up enough to push upstream.
Sorry, yes I am bad cop sometimes. :(
@bcooksley, feel free to mention that you've talked with me about stuff when filing tasks in the future. Like 90% of what shows up here spontaneously is pretty questionable, so unannounced reports get fairly strict scrutiny.
Here's the downstream task: https://phabricator.kde.org/T5406
Note that these steps depend on who is viewing the page (or, specifically, who "Responsible Users" are). More concise steps are likely:
T9372 is the main "Differential Buckets" task.
My assumption reading through docs and tasks is that "Other" means... well, other. It's been both accepted and rejected and I think it's important to convey it's not completely in one or the other state. If you set sticky-accept to false, then it will always go back for review. Maybe @epriestley has other thoughts. I would swear this came up recently though, but I can't find an absolute duplicate task.
Yes, sticky-accept is True.
Is sticky-accept still set to true then? (I think that's the default).
I've now added reproduction steps, including details on customised settings for the Differential application.
Well that's my mistake then! I didn't see it initially.
Sorry, you'll need to provide more detail on what's wrong than repeating your comment. I added the version information to the Task Description.
Also, we need steps to reproduce. the issue locally. There are setting that affect where revisions go after acceptance. I don't know what your install has those set to.
In T12323#213451, @chad wrote:We need version information on all bug reports.
This report is against Differential.
You also mention "raised the concern". Is this report against Audit or Differential?
We need version information on all bug reports.