I added the panel back as an option. I'll leave this open until we see if anyone else hits a similar case.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 27 2017
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.
It looks like we currently allow usernames to begin with _, ., and - (PhabricatorUser->validateUsername()), but maybe just do a ? for anything-except-numbers-and-letters?
A-Z and 0-9 is all we need here? Gotta remember user @0
It'd look something like this:
From what I understood, if I edit the built-in form, It would apply globally, so I only wanted that field hidden, if it was a new form. which is what I was trying to create.
Have you tried using Lock/Hide Fields to hide the "Status" field?
I am not able to edit the form such that users belonging to a certain group are not able to change the state ie: "close" a task.
Having read into other similar situations ( T11207 ) and reading that your solution is to use custom forms I began investigating custom forms.
What's an example of a specific change you're trying to make which you aren't able to figure out how to make?
Honestly I'm fine with 6600 uniques out of the box. I think beyond that people can update their image. Mostly I'd like it for individual conversations (tasks with newbies), so I don't expect collision in those cases.
Googling around I can find programmatically generated lists of 256 colors x 26 letters = 6600. We can also make background shapes. 4,5,6,7,8 sided. This would give us 33k uniques.
We can draw letters in GD, but I suspect they won't look very good compared to letters from Photoshop (bad antialiasing, limited font choices, weird alignment/kerning issues), so I'd guess it's not worth bothering and we might as well just jump straight to using generated images like Projects.
Shapes x Colors x Letters seems most clear, but will have some collisions. I can mock something up. The letters would be generated images like in Projects? Or can this be all GD? I think that assumes fonts.
commit eec6cd865c854fd00c8de41b8ca8ed0da78760e8
Author: Chad Little <chad@phacility.com>
Date: Fri Feb 24 15:21:23 2017 -0800
You are running an out-of-date version of Phabricator, from February 17th.
Please provide version information for your install. See Providing Version Information.