Jump to content


Popular Content

Showing most liked content since 03/24/2018 in all areas

  1. 1 point
    I found the issue that slows down the properties update It will be fixed in the next release. Thanks and sorry for the inconveniences. Violeta
  2. 1 point
    Hi Wolfram, Just took note of your request for the next SPRINT. I'm not 100% sure we can make it, but we'll do our best to push it Thanks for the great feedback. pablo
  3. 1 point
    Hi @psantosl, I agree that there are lots of circles, but that's the portion which doesn't bother me so much. The one that bothers me is that the color of merge links have changed to a pastel cyan which is much more difficult to see. Ideally you guys would add this stuff to preferences, and we could customize the colors ourselves (like we can for 3-way merge highlighting). On a related note, I have changesets colored by team, and branches by deployment stage. For both of these cases when I highlight a branch or changeset it turns green. This interrupts my actual decision to color these branches and changesets in a particular way. I understand that we need a way to indicate which branch/cs is selected, but forcing the selection color to be green, especially without regard to my highlighting preferences is problematic. (One of the teams was already set to a green which was almost indentical to the "current cs" green, and it really throws me off. Similar issue for branches obviously... Thanks, Ryan
  4. 1 point
    Hi @Jason H, we are indeed able to reproduce the issue. Thanks for reporting it, we will fix it asap!
  5. 1 point
    Hi, Let us try to reproduce the issue. I will update this thread with the details. Regards, Carlos.
  6. 1 point
    Thanks Pablo, I should have found that myself
  7. 1 point
    Thanks Mikael, We are fully aware of it and we expect to be fixing it shortly. We are doing lots of CI/DevOps work these days, and this one is in the list.
  8. 1 point
    Hey folks, We use Bugzilla 4.4.1 over here, so I went ahead and got the bugzilla extension up and running for that version at least. I've attached the working 'plastic.cgi' to this post. Details on changes are listed below. Please read the first item on the "XML::Simple" perl module at least, as it may require you to do more than just download the updated cgi. On a side note, it looks like "sub markasopened" still needs some help, as I didn't see this working...though I currently have no need for it so I haven't spent any time on it. I believe I saw the source for the extension's client side library somewhere on these forums, so I may grab that and start fiddling soon. It would be useful to us to be able to select a product or at least sort by product in the "Create a new child branch from task" window. Details: Missing perl module Initially, the extension (via the Plastic SCM GUI) was complaining that it couldn't connect to my Bugzilla instance. Monitoring the apache logs on the Bugzilla server revealed that I didn't have the required "XML::Simple" perl module installed. Make sure you do that! This immediately solved my connection error and allowed Plastic SCM to communicate with the Bugzilla server. A more motivated person could have plastic.cgi install this module automatically if not found. While the extension was now able to connect to Bugzilla, it still wasn't displaying anything in the Plastic client, so more was needed. plastic.cgi changes: 1. Make sure the "@allowed_statuses" array (defined at line #49) contains statuses that are valid to your Bugzilla configuration. We had a few custom ones. 2. The "@selectedcolumns" array contained an invalid column name according to Bugzilla 4.4.1: "short_short_desc". I changed this to "short_desc". This is the title/summary of the bug report. 3. The Bugzilla db query at line #116 doesn't account for the user's security groups. If you're using these in Bugzilla, the query will come back empty, preventing pending tasks from populating when creating a new branch through "Create a new child branch from task". I've added a new argument to the Search function here, "'_no_security_check' => 1", to bypass security groups. If you're uncomfortable with this, you could instead define "my $bugzilla_user = Bugzilla::User->new({name => $user});", then pass " 'user' => $bugzilla_user " into the Search function to prompt Bugzilla to search using the user's security groups. I didn't do this because it only worked when populating pending tasks assigned to the user. Checking the "Display pending tasks from all users" checkbox continued to trigger queries that didn't use the user's security group, returning empty. If anyone can figure out why, please let me know! 4. Bugzilla 4.4.1 uses "Bugzilla::Bug->comments" to store all comments and the bug description, instead of "Bugzilla::Bug->longdesc". That case is handled at line #200, but assumes first-in-last-out. It appears Bugzilla 4.4.1 uses first-in-first-out here, so I changed the reference "$bug->comments->[0]{'thetext'}" to "$bug->comments->[-1]{'thetext'}" on line #200. plastic.cgi
  9. 1 point
    Pablo - you are correct, I was only looking in the PlasticSCM client. Thanks!
  10. 1 point
    Hello Lumz, I'm sorry but I can't reproduce the issue, I use the following: echo start del "C:\Users\manu\Documents\Visual Studio 2015\Projects\ConsoleApplication1\ConsoleApplication1\bin\Debug"\* /F/Q del "C:\Users\manu\Documents\Visual Studio 2015\Projects\ConsoleApplication1\ConsoleApplication1\obj\Debug"\* /F/Q C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "C:\Users\manu\Documents\Visual Studio 2015\Projects\ConsoleApplication1\ConsoleApplication1.sln" echo end The checkin operation success and the solution gets compiled.Do you have more info to help us reproduce the issue?