Your pirate translation (006321cce76b00c3c).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 20 2015
What version of Phabricator are you on?
Your SQL is wrong. It should be:
SELECT * FROM phabricator_repository.repository_commit WHERE id == 77039
Use spaces, a positive "open source" project or custom field, make "Games Project" public, or use a public negative project which is a companion to "Games Project" (Herald rules could enforce that it was added when "Games Project" was added and removed when "Games Project" was removed).
How would I exclude tasks for projects that are not visible then? Or do I have to tag every single task with like an "Open Source" project and then make it filter based on that (this is undesirable because now every task just has a project on there so it can be queried on)?
This is expected. Queries using projects you do not have permission to see are not valid, and do not return results.
I don't think it's helpful for the withMemberPHIDs() case. Here's a specific example:
Have you considered using a nested set for the project hierarchies and build them dynamically?
I've used it in the past for hierarchy stuff and it performs very well for things like "get the sum of value X from this Entity and all of it's children"
Is the Phabricator query wrong then? I've tried loading the commit data based on the commit "id" value rather than "commitIdentifier" here:
Quote shell arguments which contain spaces or special characters. This flag behaves just like git commit -m ..., svn commit -m ..., and hg commit -m ..., and the quoting rules are the same shell rules used by every other shell program.
did you try quotes?
See also T5267. I found that task by searching for "translatewiki" in the global search.
As I wrote at T10015 Translatewiki is maybe a good, free way to translate it. They translate open source projects like mediawiki, or like phabricator maybe in future. See here for details.
I think it is better, if we have a change to do this (at least add a comment) at the console, so you can:
- Checkout what you have to do, do finish a task
- Checkout git or other at the console, switch to branch
- Run arc start to track time
- If you make a break you can run arc stop and post your progress, before you go away, so you don't have to (re)open web again, console is already open
Why do you feel it's better? My concern here is it both takes longer and is more error prone to use a CLI interface with an application like Maniphest. Is there a core problem you feel this solves outside of just staying in the console?
Dec 19 2015
Oki.
commit_id is the id column, not commitIdentifier column.
This is the current intended behavior.
Thanks!
A technical issue I'm running into is that there is pretty much no realistic way to implement $project_query->withMemberPHIDs(...) unless we already have a computed view of effective memberships.
The plan in T3670#149755 has one potentially odd implication: if implemented naively, you may not be able to see all the members of a project.
We haven't seen more of these for a few months and I've been more consistent about tidying them up so I'm just going to close this out, but let us know if anyone catches more of these.
Steps:
- You click at "edit task" or "new Bug Report" or "New feature request",
- Click at "configure form"
- Click at "view form configuration"
- Choose now from the side bar the option "Reorder create forms" or "Reorder edit form" (Second one is not reproducible here, because you got only one visible edit from at the moment)
- Then you can reorder the forms as normal user, so everybody can make chaos, if you got more forms, he can destroy the logical order.
I've updated the description, but I currently expect to promote these changes next week.
Please follow Contributing Bug Reports when filing bug reports. Specifically this report lacks steps to reproduce the issue.
Dec 18 2015
Updating to HEAD and running the clone in a loop, it still hangs eventually :(
Thanks @epriestley! I'll try it out.
@nickz I believe both issues are now fixed at HEAD. Let me know if you run into anything else.
Okay. You can implement the behavior you want like this: