From the create-a-macro page. Uploading from the home page just creates a file (which would be helpful if this task were complete :-p)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 23 2016
also, on Firefox, on our instance, I can't seem to upload a file by drag&dropping it.
also, on Firefox, on our instance, I can't seem to upload a file by drag&dropping it. I can't test on this instance due to policy.
I can't make a workboard either for the subproject. When I click "Create Workboard" it doesn't do anything
I'm having difficulty reproducing this. Here's what I did:
Generally, multiple JS issues point towards an issue outside of Phabricator (proxy, cache, update procedures).
Nothing here reproduces for me. Are you able to reproduce this issue on a known good installation of Phabricator? Either here or on http://phacility.com?
In T10427#161230, @rbalik wrote:
From the DB: P has viewPolicy: P, editPolicy: admin, joinPolicy: admin.
What are the view, edit and join policies of the parent project set to?
Ah, interesting. I have F1 bound to "Expose: All Windows" so the flow for me is "Click > F1 > Drop Anywhere" to save, then "F1 > Drag > F1 > Drop" to load. I'm pretty sure I can get through that faster than I could copy-paste/type-select a file by Fxxx or from a browser UI.
I just encountered the same error message.
Oh ok, so I guess that doesn't matter then
Note that being an administrator doesn't matter: administrators have no special privileges, and can not bypass policies. See:
In general I find drag and drop workflows to be slow and annoying (with rare exceptions, such as workboards). In addition my browser is full screen so the actual workflow involves opening Downloads, finding the file among the hundreds of files, and reuploading it.
Hmm, that looks like the same process.
In T10349#161180, @cburroughs wrote:Initially, I've found myself digging iterations for the magic workboard columns even for "evergreen" things that are not really iterations. I wanted to reorder them, but I'm confused what the UI is trying to tell me. Can I not re-order iterations, only control how they appear relative to "normal" columns, or is this busted?
Thanks, your reproduction instructions are clear and complete. I was able to reproduce this by following your instructions and narrow it down to a root cause. This should be fixed shortly.
Thanks! This will be in next weeks stable release?
I'm having trouble reproducing this. I tried to follow the instructions you provided to recreate the issue, but didn't seem to experience it. Here's what I did.
In T10412#160950, @epriestley wrote:Change milestoneNumber in phabricator_project.project to reorder milestones.
Yeah, running a version from Friday: 5eecff91cdd3
Hi! Can you please let us know what version of Phabricator you're running?
In T10408#160933, @chad wrote:so the relation with the project can still be identified after moving the task to a different space
This seems very brittle overall. What's the root problem you're facing that makes this a suggested solution?
If I was to delete the broken project (bin/remove destroy PHID-PROJ-...), would that clean up the database in such a way that the broken links were also removed? Or would that break the database even more?
In T10350#160815, @urzds wrote:[...]
It appears impossible to clean up the relation between the task and B(Z) / B(A) from the UI.
@epriestley, test files in last comment indicate 31 can decompress gzip properly.
please check it.
Should be resolved at HEAD. Thanks!
Initially, I've found myself digging iterations for the magic workboard columns even for "evergreen" things that are not really iterations. I wanted to reorder them, but I'm confused what the UI is trying to tell me. Can I not re-order iterations, only control how they appear relative to "normal" columns, or is this busted?
Reading the code around /usr/lib/python2.7/dist-packages/mercurial/sshserver.py:32:
def getargs(self, args): data = {} keys = args.split() for n in xrange(len(keys)): argline = self.fin.readline()[:-1] arg, l = argline.split() if arg not in keys: raise util.Abort("unexpected parameter %r" % arg) if arg == '*': star = {} for k in xrange(int(l)): argline = self.fin.readline()[:-1] arg, l = argline.split() val = self.fin.read(int(l)) star[arg] = val data['*'] = star else: val = self.fin.read(int(l)) data[arg] = val return [data[k] for k in keys]
In conclusion, we should never add options to the product.
(The difference between the dark and default background colors is so subtle on my monitor that I never noticed it.)
Oh, I do have that set locally -- I thought phui-theme-dark was just the default (since we got rid of light?) but this fixes itself if I switch to, e.g., the red header.
Internally, we track "explicit members" and "implicit members".
Parent projects can not have explicit members. The explicit members are moved.
However, all members of subprojects are implicitly members of ancestors, so they're still present as implicit members of the parent.
I'm hoping to navigate this without adding more concepts to the UI like "explicit members" and "implicit members". One thing I'd like to do is show which subproject(s) a user is a member of in the "Members" panel for parent projects, which might help. We could also add a line of explanatory text, and/or rename the panel to "Members of Subprojects", although both clutter the UI to explain a one-time facet of the model.
I'm not removing the live preview. I'm just focusing on the box itself.
Oh, is this just a dark-theme issue? That seems easy to fix.
I feel like I am admitting a secret weakness, but when I use GitHub or another UI with a preview toggle I find myself missing the live updating preview that Phabricator has. I hope this admission does not invalidate my elite command line user neck beard.
In T10374#161140, @epriestley wrote:For anyone else with other use cases in this vein (roughly "select an existing file from Phabricator" as an alternative to "select a file from the filesystem"), can you run through the scenarios in which you'd want to use this, and why it's preferable to just downloading the file first?
When creating the first subproject there is a note that all members of the project will be moved to the subproject. In fact, members were copied to the subproject
T10349 has a similar use case, where a user would like to select an existing file for use as a cover image.
We just played around with projects, subprojects, and milestones as we wanted to figure out a nice way of organizing work. We fell over a few inconsistencies/issues/bugs:
Thanks for the heads up. I will contact my user with this information. What you said make totally sense to me :).
Thanks, that's helpful.
This gets a brief mention in the documentation, but generally:
Sorry I totally forget the version:
phabricator
023cfbb23af36b7f15be86a1f5950b62d68b246d (Mon, Feb 22)
arcanist
fcc11b3a278199fa15b90692aba65f54fef5d7f7 (Wed, Feb 10)
phutil
f43291e99d36045bc459e5133454c0d8fd8768ea (Jan 21 2016)
Hi! Can you tell me what version of Phabricator you're running?
In the very, very general case, I think it's undesirable to favor "N" over "U" because the reports could be coming from two different engines, only one of which knows how to execute the lines.