In T15043#1246, @TitanNano wrote:
Indeed.
In T15043#1246, @TitanNano wrote:
Indeed.
@TitanNano: One way to store the type, without changing any schema, would be to drop it into the metadata json blob which columns already use for recording which column is the 'default'. Unfortunately that isn't the most convenient thing to query, however, it's not that bad thanks to mysql's json functions.
Just having a dropdown here would be enough, I guess?
It wouldn't be too hard to add a type to columns but we'd need a way to set the type from the UI somehow.
I started to implement this as a new herald action. There is just one major problem. I would have to load all columns from every project and present them to the user. A user could then select one specific column of one specific project for his herald action... This seems kind of pointless to me. It's way too specific to be usable.
This is something we probably want to wait for the rebrand to occur as it could be considered "releasing". Granted these repos are already public so it wouldn't be too different than what we have now.
Thanks for looking into this. I ended up submitting the initial simple change to fix fwrite vs. fprintf to upstream and discussing with epriestley he recommended to instead just remove the use of logging. I ended up making a larger change that also corrects the error-handling when running arc liberate. We can probably hold off on changes here and merge in changes from upstream -- https://secure.phabricator.com/D21718
In T15002#1224, @TitanNano wrote:I just wanted to note that Phrequent is an integral part in my company, even though it's a prototype. We heavily rely on time tracking.
In T15002#1203, @MacFan4000 wrote:I’ll note here that I’m going to work on creating projects for some of the prototypes that do get used.
Now that I look at this some more, this isn’t quite done - there are still some components of phorge that are missing projects.
Looks good, hopefully this can be landed some time soon.
I’ll note here that I’m going to work on creating projects for some of the prototypes that do get used.
I also agree that #3 seems promising. FWIW it's incredibly easy to develop new herald actions and as long as the current herald rules do the thing you want to do then the action would be very straightforward. Maybe the usability would be improved by exposing the rules that affect a board through the workboard UI instead of having them scattered around random and disorganized herald rules in the herald ui?
In T15044#1193, @speck wrote:@TitanNano additional context around the development style that causes this issue to come up would be useful to include here.
In D25015#678, @speck wrote:It looks like there is a JX.phtize() which appears to be used to create a function that mimics pht() in JavaScript but I believe requires that whatever is passed to phtize() is effectively a map of translations which is presumably passed from the server somewhere. I've not yet uncovered this later part.
In T15044#1193, @speck wrote:Functionally I think this makes sense, though from a higher perspective the concept of "multiple authors on a revision" might need to be discussed and fleshed out.
Technically this workflow can be supported today as arcanist will allow you to make updates to a diff that was originated/authored by someone else however in my experience this tends to be fraught with issues [...]
I didn't manage to get #phorge:libera.chat to work, but here's what I did:
Ref also Git Commit Message Conventions. Adding a Co-authored-by: name <name@example.com> trailer to the commit message seems fairly well-accepted, at least for Git. GitHub and GitLab both recognize and parse it when present.
Thanks for landing, and sorry for the delay; was away on vacation. I'll try to be more responsive in the future!
Automated Landing should be what adds the "Land Revision" button to revisions -- so not fully automated but allows someone to land without needing a local clone to manage.
Functionally I think this makes sense, though from a higher perspective the concept of "multiple authors on a revision" might need to be discussed and fleshed out.
I agree with @CSharp that option 3 is probably the best approach here. It looks like on https://secure.phabricator.com/T6409 the initial request was that items get automatically moved based on state change and the main pushback is against the design of an approach like 1 or 2. I think setting this up utilizing Herald makes sense though. I wasn't aware that triggers/transactions weren't fired from both locations though. That might be a bit involved.
I'll try to look into feasibility of this later this week. Presumably it shouldn't be too difficult, adding a few configs to point to the certificate files and updating the DAO (I think is named Lisk?).
In T15035#1188, @speck wrote:@TitanNano with the matrix bridge up could you provide instructions on how to connect to that? I setup the Element client on my machine but I'm not sure how to get on that phorge channel.
@TitanNano with the matrix bridge up could you provide instructions on how to connect to that? I setup the Element client on my machine but I'm not sure how to get on that phorge channel.
I would support using approach number 3 and actually consider moving the triggers into Herald in the long run. Triggers are only dispatched from Javascript when moving the items on the board, but moving them within a task using the "Add action..." dropdown does not trigger them.
In D25019#617, @speck wrote:This looks good to me.
I'm curious how often these scripts are used. I haven't used them for any of the installs I set up but I largely wasn't aware that they existed.
Thanks for submitting these changes!
Thanks for submitting this!
Also when I look at a diff on upstream phabricator i see a land revision button - but I don’t see that for diffs on this instance.
It looks like there is a JX.phtize() which appears to be used to create a function that mimics pht() in JavaScript but I believe requires that whatever is passed to phtize() is effectively a map of translations which is presumably passed from the server somewhere. I've not yet uncovered this later part.
@speck for rARC Trusted Contributors can land but rP is restricted to Blessed Committers
I'd suggest starting of the starmap by shedding some/most of the applications that were not part of the core of Phabricator or have been in the Prototype phase for a long time, allowing the project to regain focus and improve on the things that make Phorge unique. This would provide a number of advantages:
I think these changes look good. Prior to landing this should pass unit test runs. I created T15042 as a means to make landing changes easier and it should also involve setting up a staging area which then runs both lints and unit tests.
Thank you for the submission @roguelazer!
I'm going to look at trying to land this today. Additionally I created T15042 to avoid situations like this where the changes are accepted but don't get landed for some time.
Reference to the last Phabricator starmap prior to deletion. Phorge's starmap will likely align very closely with Phabricator's, initially.
With this change these log messages are being written out, even though the default of $this->quiet is true. I think this is because rebuild-map.php script unconditionally calls setQuiet() with the value it's passed from the command-line, however ArcanistLiberateWorkflow does not specify or pass in a quiet argument.
Turns out there is Javelin support for "copy text" already implemented - I think it's used when copying from 2-up display, or when white-space is visible.
Anyway, I have an example code at https://secure.phabricator.com/P2080 for a button that copies arbitrary text.
I think I just set that via "Global Default": https://we.phorge.it/settings/builtin/global/