That is, I changed the configuration to fix things on this install; the new task details describe fixing the root issue.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 16 2015
This was a configuration issue which permitted configuring a currently-invalid mixture of "Space" and "View Policy" visibility.
@Suhasini_thakur The message tells you how to fix it. Did you attempt to follow the instructions it provided?
Phabricator is installed properly.But after installation it shows some error in mysql.
@ablekh i just added a "fastcgi_param HTTPS on;" in nginx config for phabricator
@nnnn20430: Thank you for the reference. Did you apply the patch, included in T9293: WebSockets access problems with reverse SSL proxy ?
@ox: stable is very close to the edge. I think if you want production use, you should just use stable
ok figured it out the problem for me was because of this bug T9293
http://www.tecmint.com/install-phabricator-in-linux/ should not be followed. It is an out of date guide. We only support installing from our guide.
I created user from browser but it was not working then i created user from command line with another user.
I have installed phabricator from https://secure.phabricator.com/book/phabricator/article/installation_guide/ and www.tecmint.com/install-phabricator-in-linux/
I did not create any user from terminal before visiting it in the browser.I created user from browser but it was not working then i created user from command line with another user.
Please let me know about this.
How did you install Phabricator? Did you create a user from the command line before visiting it in the browser?
Hello,
I have installed Phabricator on ubuntu 14.04.But when I enter phabricator.domain.com,it shows an authentication error "Authentication Failure
This Phabricator install is not configured with any enabled authentication providers which can be used to log in. If you have accidentally locked yourself out by disabling all providers, you can use phabricator/bin/auth recover <username> to recover access to an administrative account."
@epriestley I sure hope there's a badge for whoever creates T10000...
I got the same problem :
Dec 15 2015
Is there an expected date when this change will be safe for production use? That red warning bar at the top of the summary is very intimidating, though I want to keep our instance responsibly close to the edge (should I just use stable?).
(The first change attached here was the instance sync change.)
This was easier than I thought and now in HEAD. Should go out Saturday unless churn related to T9905 makes me uneasy about promoting to stable -- I'm currently feeling good about promoting, but still have three full days to mangle master.
i have same problem, the notification server is working and it logs notifications like on new message in Conpherence app, but nothing get's updated in notifications ui and it also just says "Setting Up Client".
Verified! You guys rock!
This should be fixed in HEAD. Let us know if you're still seeing issues or we missed anything.
Even if it's not an everyone has a blog case, again, I can't imagine it's a common use case to regularly be switching blogs to post on. Again, this is just a convenience function (a "New Post" button that creates a new post for the last-posted-to-blog). Not required, just a nice to have.
We use git-phab, a tool which creates a task per branch and keeps the commits in the branch and the diffs of the task in sync. https://phabricator.freedesktop.org/diffusion/GITPHAB/ What this means is that it allows us to change the order of the diffs more easily, so in our case it will happen more often!
Ah ok, I don't think we've considered the "everyone has a blog" case. It might get hairy.
Oh cool - that's a useful shortcut. But imagine that the primary use case is this sort of note taking where everyone has their personal blog, I anticipate that 95% of the time, people will be writing blog posts on the same blog they last wrote on. For the 15 people on our team, 100% of us only write on one blog which is our personal blog.
The only feedback I have is that since the "New Blog" button was added top Right (instead of, for example, "New Post" which would default to, say, the last blog that you posted to), I inadvertently created a new Blog when I meant to write a post.
Sounds like you're using it as we do, though.
Well we're about to unbeta Phame if you have any use cases we're not thinking of.
As an aside, if you guys ever want insight from heavy Phab users, let me and Nico know! We're so deeply integrated now...we even automate the creation of Phab tasks via Salesforce to manage our entire Client Services team's work flow to onboard new clients. :)
Awesome :) yes, I don't see any of us caring about the slugs. In fact I remember it being a bit of a nuisance to do this because we'd have 15 people all with the slug of, for example, 12/10/2016, so we'd all have to make them unique. :)
ah, true
Since slugs no longer need to be unique, I'm just going to simplify this whole process and generate them automatically from titles.
When I first wanted to report a bug to a project that uses Phabricator, it took me several minutes (!) to figure out how to login and I'm used to all kinds of bug-trackers (mantis, jira, trac, ...).
We don't have external references to Phame, only internal references within Phame itself. So no need to have the old urls work in that regard. It's just that clicking the links in the phame UI itself is an important piece we'll need to work.
Also, is the fact that the URL scheme changed an issue (i.e., do you have a lot of links to the old URLs in external systems)? We weren't aware anyone was really using Phame seriously, but I can write a little extension you could use to keep the old redirects working for a while if that's also causing you pain.
(the reason this issue is exacerbated for us is because the titles of all our posts are dates, which many folks use /'s for, so we have a ton of posts with this issue)
Yeah it's a critical part of our workflow :) back at Google there's this concept of "weekly snippets" that the whole company used to use and our engineering team here at Doctor.com models after that. It's really useful to get visibility into work. :)
We could also just bring that patch upstream, but I think allowing "/" in slugs is probably a decision we'd regret in the long term.
As a workaround, you can apply this patch locally, which should make things work for now:
I am stoked someone uses Phame though!
(maybe we can hack the route?)
I don't know how involved a migration script would be, @epriestley?
You can use the URL /phame/post/edit/775/
@chad Hi Chad, so how can we remove it if we can't edit the post? Is there a workaround to edit the post? Or some manual database change we can make? We have literally hundreds of blog posts as we use this feature internally to track weekly work (hence the urgency as now our entire company has lost visibility into each other's work), so it would be a nightmare to do manually...
Based on https://phabricator.freedesktop.org/T3491 the root problem to me looks like "it should be easier to review large batchs of diffs". Right now you're using Maniphest as a stop-gap solution that should be correctly resolved Differential's Custom Query
This is an intentional decision.
You'll need to edit your title phame_title to fix the 404 for now (I don't think it's worth providing a retroactive fix). We should have always been removing / from Phame Title as it would have always 404'd with Live View.
@michaeljs1990. You seem to have another issue.
It looks like it counts the total working copies. I thought the limit is for every single repo: when I set the the limit to be 5, I expect that every single repo can have 5 copies at most. This is not scalable: when more and more repos get created, we have to adjust the limit.
Also why can't a new lease get another resource when previous lease holds a resource? I set the limit of the working copy to be 5, so there should be enough resources available to be used.
@silverskysoft that's unfortunate, but thanks for letting me know.
When the reviewer looks at the task to review the diffs, he needs to start somewhere and end somewhere. This is where the diffs list help: the reviewer will start at the top and finish at the bottom. Currently the diffs are ordered by creation time. Normally this works ok because the newer diffs depend on the older diffs. But if a newer diff is made a dependency of an older diff, the order of the list is not relevant.
w00t w00t, I got something out of this bug report after all!
I inducted you into Community so you should have sweeping editorial powers once again.
I don't have a shell alias, but I do have a wrapper script around arc. Doh! I totally forgot about that. Sorry for the false alarm.
I can't reproduce this:
I am curious about this as well or if it has been addressed some other place. It's pretty easy to manually resolve the issue most of the time however I am not sure what the proper action would be after doing this? Does phabricator expect you to arc diff after you manually resolve it?