The key ingredient is to next set the default View/Edit policy of Maniphest to the Employees group (for Default Space which user is not accessible to)

I only approve "code" from @epriestley

what's your policy on supporting "random" PHP snippets from "sources" into Phabricator code

should send it to the log

phlog($var);

i have hosed it?

sosneaky

phlog

itsasecret

shh

What is the best way to log something to the web server logs? I've been mostly using exceptions but that's proving to be more and more cumbersome.

FWIW I do truly believe we have a bug here, just no idea where. Might be worth adding some logging?

I tried reproducing this on my phacility instance but I couldn't. Additional steps I took to mimic my setup were:

1. Make the Default Space only accessible to a specific group (say, Employees)
2. Make the default Maniphest Task Form visible only to Employees
3. Make the new Contractors task form default to being in the {Contractors} Space, and only visible/editable by Contractors

I'm also running last week's install
libphutil: 24ede7a5dbfd38079c87fc61de64012551965837
arcanist: 822bc53ca306e06314560d8a76f68771d732e8e0
phabricator: 56dd1b297c3e5cdbb477acc7435d6aa5749f33f2

I am seeing this too. I've not confirmed 100% but I think it has to do with Spaces:

1. Create a Space (not the default Space) visible to Project Contractors
2. Create a Maniphest Task Form (/transactions/editengine/maniphest.task/) that is visible to Contractors, set as being Edit Form
3. Create a User that is only a member of Contractors and which does not have access to the default space
4. Log in as the new user and attempt to create a new task using that task form. You will be presented with the "Edit Locked Task" form.

Still facing the problem with Locked task in any new task created. Even on new install. It's database/app config. Please guide where to check about that "locked task" flag BEFORE is created object.

Try as I might, I cannot reproduce this in a test instance hosted by yourselves.
The on screen description is the same (HEAD -> master), but the actual URL it goes to is different compared to my instance, even with the same repositories loaded.

Brand new install on another VM, same Database server - same error. So can assume that the bug comes from data stored in database.

Feel free to file a new report if you are able to come up with clear, working reproduction steps that reproduce this issue on a clean install.

This doesn't appear to be moving toward becoming an actionable report.

Sorry, we don't take bug reports as support requests. Have you read and followed Contributing Bug Reports?

Please let us know if we have missed out any settings.

After installing the phabricator we created a new repository.

When the repository is in inactive state the "ssh git clone...." of the repository is shown up.
When we activate the repository and try to see the repository mail screen, the below error is showing up.

Bug reports need complete reproduction instructions and complete version information. See Contributing Bug Reports, Providing Reproduction Steps, and Providing Version Information.

Did you try to enable PHP's error logging to get more output?

That's the big problem, the logs say nothing.

Ok, so I have several custom fields in forms such Task or New bug. Could that lead to that de-effect ?

I have no idea either. We need reproduction steps. Reinstalling will not resolve this.

There is definitely a bug here, I just have no idea what configuration of forms leads to it. @epriestley might have other guesses.

I'll wait Friday stable.... today I've switched from stable to master branch. The install is if I can say untouched and every Friday updated.
Just git pull in 3 dirs and that's all. Use well known bash script for that. All customization and setups are stored in SQL database.
What else steps to report - just pressing New task and appears that.
Is it an option to clean up folder and make clean git clone ?
If tomorrow stable don't resolve that nasty problem will proceed with clean install.

Thanks, but we really just need the steps to reproduce the issue locally. I don't know them, I have no guesses as to how to get an installation to do that. Without knowing how to reproduce your bug specifically, we have no idea what to look for or if we're fixing the correct bug. This is a huge time burden for us, and is outside what we cover under "free support". We require every bug report to provide these steps for us, since Phabricator is a free product.

Usual "here in my machine works fine".
Hereby is screenrecord to convince you
http://srecorder.com/s/3huk
Or just give a joker where to look after for raised flag of locked task or like that.

I found that svn repo import was stuck on a very large branch import. I marked the repo as imported, suddenly the herald rules and notifications started to work properly (which was my other problem that I wanted to solve with my instance).

We need reproduction instructions which allow us to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

Feel free to use a Phacility Test Instance and record your steps, thanks!

update: We used default mount options in /etc/fstab for the disk containing repositories

noexec,noatime,nodiratime

we fixes the push logs and herald commit content hooks issues by changing it to

noatime,nodiratime

thanks!

We migrated phabricator last months just realized somehow "Push Logs" are not generated anymore (the last push log was created just before the migration)
and I guess commit content hooks are somehow related on push logs (?)
May I ask what can I check if the push logs aren't being created?

closed per user request

@epriestley Please close this task (I can't).

We haven't received any more information about this in a little more than two weeks, and don't know how to reproduce it so we can't move forward. Feel free to file a new task if you're able to come up with reproduction steps which work in a clean environment.

We haven't received information that lets us reproduce this in about a week.

@pmatos, Have you seen the Providing Reproduction Steps page? What kind of instructions can we add to it to make it better?

@epriestley I understand it's upsetting for someone to report a bug like I did. The problem here is that having no experience with Phabricator internals or webapps, I have no clue how to even give you the slightest hint of how to reproduce. For example, in my case, I got as I mentioned a problem with the daemons. I needed some further help from your side to actually create a bug report that actually helps you.

Offhand, I really have no idea how to get an installation into what you describe, and no real suggestions on how to resolve it.

If you can come up with reproduction steps, let us know and we'll reopen this task.

To be clear, we don't take bug reports without reproduction steps. I'm afraid we can't help you further.

Hi Chad,

I can't reproduce this, here's what I did:

BTW, I also tried with the phabricator latest release (as below) by taking DB dump from previous into new one. But issues still remain same.

Please find the version details

Sounds good, let us know if you come up with repro steps.

Ah, ok, please feel free to close it till I can figure our reproduction :)

This isn't a bug report we can accept upstream. See Contributing Bug Reports for help. In particular:

This isn't a bug report we can accept upstream. See Contributing Bug Reports for help. In particular:

I see, it must be a text file.

Safari / OSX:

This report is missing version information. See Contributing Bug Reports and Providing Version Information for help. To move forward:

@epriestley That's fair, I'll see what I can do.

Because of the complexity of building a reproduction case and high chance that this is a wild goose chase, we'll move forward with this after a community member confirms it reproduces for them. See T12134 for some discussion. See T12129 for a similar recent report which was a time-consuming wild goose chase.

perfect thanks!

That error makes sense,

• Ubuntu 16.04
• PHP 7.1.1
• nginx 1.11.9
• Galera Cluster MariaDB 10.1.21

For anyone who discovers this task, the issue appears to be related to the SimpleXML PHP library. This must be installed and enabled for the system PHP. Ubuntu 16.04LTS includes PHP7.0, so if you do any magic to run PHP7.1 or PHP5.6, your system php will not match what is running on phabricator.

Okay, we will try to upgrade phabricator in our next weekly maintenance window tomorrow, I'll update you with our result later

your phutil is 3 weeks older than the rest

I couldn't reproduce this.

(I preemptively set the project back to Needs Information since the followup didn't involve reproduction of the issue on a valid install)

OK, it seems utcInstanceEpoch is only used in child event of recurring events according to the code. After I canceled the recurring event(E4), there is no more error in phd log.

I just created a simple test event and the utcInstanceEpoch column is still NULL. What does this column mean?

just FYI, I checked the database and found the utcInstanceEpoch is NULL for some old events, which maybe caused by bug in data migration during upgrade.

Erm… I was just asking for time repository update on the repository you have already cloned, hence the 15 seconds. If I understand this correctly, you seem to indicate that it would still be too much. I'm having a hard time understanding, but if you're adamant about this, then there is nothing left to say :)

I added some log in src/applications/calendar/storage/PhabricatorCalendarEvent.php before line 728 like this:

if ($this->isChildEvent()) {
      $parent = $this->getParentEvent();
      error_log("utc string:".$this->getUTCInstanceEpoch(),3,"/tmp/phadebug.log");
      $instance_datetime = PhutilCalendarAbsoluteDateTime::newFromEpoch(
        $this->getUTCInstanceEpoch());
      $recurrence_id = $instance_datetime->getISO8601();
      $rrule = null;
    }

It indicates $this->getUTCInstanceEpoch() returns empty or null. Any help for this? And I guess it should be related to some recurring events.

If you do find a way to reproduce the bug, please reply back and we'll look into it.

We'd be happy to help you further under Phacility Consulting services. We unfortunately do not take bug reports without reproduction steps or against prototype applications (Calendar).

No idea, I guess this is something related to the Calendar events in my install as you mentioned. I'm wondering if there is some place in the code I can add some lines to log/debug the actual event and the date/time string which caused the error? I can edit the source and run it again.

Thanks! Do you know how we can reproduce the error locally?

I'm still seeing this in the latest code:
phabricator

c63ba8337ec7e7f021f17c972e9a2a751f6280e2 (Sat, Jan 21)

arcanist

9503b941cc02be637d967bb50cfb25f852e071e4 (Sat, Jan 7)

phutil

6d8f5a783ebe7993b78632091507f6d7d8cbc215 (Sat, Jan 21)

And if I gave you a precise estimate you could be sneaky and just divide it by $1,500/hr to get the answer without paying for it!

Obviously, we can't just hand out estimates for free. Converting units and multiplying numbers together takes away valuable time and resources we could be using to develop Phabricator.

What'd be the fee for that 1 second command and a 5 second copy/paste?

I'd be happy to, see Consulting to move forward.

Could you at least give me the time output for the broken/test repository update on your test system, so that I have a baseline for comparison later? Thanks!

Sounds good. I'm going to close this since it doesn't seem to be moving toward becoming a bug report which we can accept upstream.