After D12336:

In D10674#228773, @asherkin wrote:

In D10674#228771, @Ondrej wrote:

It's shame that such useful code is waiting years for review...

Per policy, Phrequent is a Prototype application and thus external contributions are not accepted for it.

In D10674#228771, @Ondrej wrote:

It's shame that such useful code is waiting years for review...

It's shame that such useful code is waiting years for review...

We haven't seen more interest in this in several years.

Thanks for link, i know that page already. This feature is the one missing for us to switch from another well-known system which have more and more performance and billing problems.
That means we can finish the development of this one : that's why i asked for a status, rather than a boring "will it be ready next week" :)

See Planning.

I just applied the patch (roughly) and the "edit" pen appeared in Phrequent. By the way, clicking on it lead to a 404 Not Found error page.

any news here? the implementation seemed on a good way but there was no update since July 2015

Adding a input box to the top so wherever you are you can just type in the task number you want to switch to, would be a plus.

No, it would not.

Thanks for the hint!

Go to Conduit on your install.

Phrequent is a prototype application, and we don't provide support for these types of apps. Mostly it's expected that they will be incomplete and once we do move them to being officially supported they will have these features naturally (for example Conduit is "free" for any modern application.)

Is documentation available through other means than Conduit itself?

Phrequent is not installed on this server. Conduit only shows methods from installed applications.

Hooray!

This was fixed in rPb28da10336ca 😄

Unfortunately, this is so far afield from our roadmap that we don't have room for this year, even under paid prioritization.

Related to paid prioritization, how much would it cost to terminate this task and also the ability to edit the time entries after validation (man does mistakes).

Just throwing in my support for this. I'd love to move away from paid services (aka Jira + Tempo) and use Phabricator.

Please see Planning for information on timelines.

It's been 2 years since this task was created ( my company isn't able to use Phabricator because this functionality is missing ). Do you have any update on current situation ?

I'm going to write a CurtainExtension for it (I just missed it in the original round) but you might have to fix my bad stylin'.

Not sure offhand how to fix this.

See Prototype, we don't provide bug or feature request for prototypes unfortunately.

i totally agree we need a time tracking in phabricator

Please take a look at Kimai for some inspiration on how to implement Phrequent. It is very clean and simple and easy to select, start, and stop timing events. Phrequent also needs the ability to track against more than just tasks. For example, our organization would use it to track time against support calls, etc.

It seems that AphrontFormDateControl is responsible for the wrong time formatting and not the phrequent code.

Now I have the edit function. Thanks.
There's a slight misbehaviour that the users time format is not respected. I'll try to change that first...

@Aronnax You're right I've forgot the adaptions in the listing:

@Aronnax, ah, okay, my mistake.

@CodeMouse92 I may have not been clear what I meant. In prequent-edit.tar.gz are some files missing to make editing work. So @witrin may pack his phrequent folder so we can get the missing pieces and make it patch out of it.

@Aronnax, you need to download a fresh copy of the Git repository yourself, and then look under applications/phrequent.

Hi @witrin. Thanks for the files!

@Aronnax @CodeMouse92 Here you go. Hope that's all ...

@Aronnax @CodeMouse92 I'll try to upload the patch asap when I find some time. Currently I'm pretty bussy.

I just tried to apply https://secure.phabricator.com/D10162 to current stable but it doesn't work really. It seems a little has changed in Phabricator. Edit function throws an exception and PhrequentSearchEngine::renderResultList() returns a PhabricatorApplicationSearchResultView object in current code but nor in the patch. Unfortunately I'm very new to Phabricator so I'm not able to fix that easily.

The way we split up projects, it would be useful to also have a total tracked time. We have sprints that are their own projects, and each individual application is it's own project, so tasks have multiple projects tagged on it.

I'm still rusty on my PHP, but we might be able to work together and pull it off. I think it would be fantastic to get that on Phabricator so this task can be marked as done! We might just need to message each other on Conpherence if I get stuck on implementing your patch.

Wait this is even worse. I think I haven't published the add/edit feature ever separately. But this doesn't change my offer: sending you a patch and you could do the rest...

@CodeMouse92 The code is running in a production environment on the latest codebase. The problem is just this feature is bundled together with two other features in one branch and I really don't know how to select a lose set of commits using arc diff. I've tried once but I was only able to use the latest nth and that's not helping here. So this would mean I've to create a patch clone the repository download the older patch from the revision put them together and then I could use arc diff (but without the tests because I've no development environment). So when you could help here a little bit, I could send you the patches and you could do the rest (publishing them)?

Hi @witrin, I just had an issue this week with someone who really needed to edit a time entry that got mangled. Would you mind reviewing your add/edit code given the latest codebase in Phrequent, and creating a new diff? Perhaps it'll get accepted, plus I can at least patch it in to my own copy. (I hope the rest of ya'll don't mind my saying that, but I'm pretty darned desperate for this.)

Actually, I have to agree with merging this into Fact, otherwise we wind up with duplicates of common code.

I see no added value by bringing this into Fact or another reporting system beside the effort to implement this. Provide access to the collected data through common formats (XML, CSV etc.) instead would allow to use any tool to produces any specific report which is needed by the user (see T5151 and T5150).

I'm just curious because of your comment, which was the reason for my last revision:

There is nothing you can do to speed this up. See: