Oh, my apology for not replying on your previous comment, somehow the notification slipped through and I'm not a very regular visitor of this Phabricator instance.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 17 2016
I'm going to merge this into T10967, since after digging around in the code a bit recently it seems unlikely that we'll pursue the infrastructure changes required to fix this outside of the context of that larger infrastructure change.
I can only reproduce this if (3) is changing "Visible To", exactly: i.e., same file policy scrambling issue as T10778. Should have the same fix.
Ref T10778
Likely the same as T6815 since I think they're the same code.
May 16 2016
Not sure if this should be another bug report but the / that is added at the end causes issue when using anchor tags i.e if [[ ../2016.19#gotolocation ]] was the markup the link would also be broken by adding a / at the end.
This is almost definitely T8298, because % can't be properly escaped on Windows right now.
This specific issue also happens on my computer, which is running Windows 7 SP1 with PHP 5.6.20
May 15 2016
It's not email client dependent - Phabricator is writing out the wrong URL when sending email.
May 14 2016
Which email client is this about?
Beat me to it :P
May 13 2016
This isn't a bug, the block has a performance-motivated explanation in a TODO comment above it:
May 12 2016
Thanks!
OK so they have to make it at step 3, before his first session expires, otherwise I'd have to update it directly in DB.
They can link their accounts in Settings → External Accounts.
OK for the security feature, but in my case LDAP is the only auth provider (username/password is disabled), so my users can't link their accounts.
It's on an invisible page <_< >_>
This is expected. This is a security feature, not a bug. Just because you have a Phabricator user account named joe does not mean you have authority over the LDAP user account named joe, and vice versa. In many cases LDAP and Phabricator user account names differ. Users must prove they have control over external accounts by linking them before they can use those external accounts to access Phabricator.
I didn't see anything related in recent changelogs, so I didn't update out instance.
But if you could wait a couple of days, I could try to reproduce.
Is the issue reproducible with an updated version of Phabricator?
May 11 2016
Merci :)
Works like a charm. I never imagined this could be so quick ! Many thanks
This should now be fixed in HEAD of master -- try updating again? You'll need to git pull in phabricator/ to pick up the change.
This should be fixed shortly by D15876.
Indeed, it's fixed ! Thanks
May 10 2016
This may have been fixed by D15507. Otherwise, we can't reproduce it, so we can't move forward. See Providing Reproduction Steps.
Awesome! Thanks for doing all the work to figure out what was going on. I'll get a diff out to apply that fix in a slightly nicer way.
Yes, that corrects the issue!
Thanks for hunting that down!
OK, I found the issue and a fix/workaround:
May 9 2016
I can't reproduce this:
D15873 makes this explicit in the dialog.
Or see @avivey's far more complete response.
We don't support HHVM.
- Neither HHVM nor proxygen are officially supported by Phabricator, see T1261 and https://secure.phabricator.com/book/phabricator/article/installation_guide/ for a list of supported platforms.
- HHVM does appear to support rewrite rules - see https://docs.hhvm.com/hhvm/configuration/INI-settings#server-mode__virtual-host-format, though it might be a little hard to configure.
- You can apply this patch locally, but there's no telling what else will fail to work with HHVM.
May 8 2016
The difference with our interface : I have not installed "http git" only ssh git
The difference with our interface : I have not installed "http git" only ssh git
I cannot change the Space by default
I can't reproduce this. Here are the repository policies:
I ran into this same issue, it was caused by user error, but the error handling of diffusion could still be fixed. Here's how to reproduce:
May 7 2016
May 6 2016
That actually works! Thanks :)
Haha, alright. You might be able to add it to conf/local/local.json manually as a workaround, but I'm not sure if that'll work or not.
It involves dirty solutions to idiosyncratic problems, maybe we're both better off not talking about it.