I've got a program that I've been working on at home for a while, and I decided finally to throw it up on SourceForge. SourceForge offers Tracker, MantisBT, or Trac for bug tracking.
My app already has a "Sorry, an error occurred" dialog, but I'd like to add a "Complain about it" button that will submit a bug to my bug tracker. Has anyone tried to do this with Tracker? Can you submit anonymous bugs via a query string interface, or something along those lines? Or, if Tracker can't do it, how about MantisBT? Or Trac?
Programmatic access:
Mantis has a SOAP interface;
Trac has an XML-RPC interface.
If your application happens to be built on Eclipse, you can use the existing Mylyn plugins - they're both offered with 1-click install since version 3.2 (reference).
Also, Mantis 1.1.x (and perhaps later 1.2.x) has a php script (core/checkin.php) that can be called from a post-commit hook when the repo and mantis live on the same host. You just need to provide the glue for the hook, e.g. bash, and either commit all notes as a user defined 'vcs' userame or make a small modification to the php to determine the user making the commit.
In the later 1.1.x versions there is a checkincurl.php that will address usage when mantis and the repo are not collocated.
Related
I am using latest okhttp and when using at home it connects just fine. Inside a company it displays dialog box for approval to connect to a server. I do not want the user to see that dialog box just connect silently like it does for me at home. How do I get it to do that? I used httpclient from Apache and it does not do that. I wrote my own code to determine proxy and added that to Apache client code and it does not ask for connection approval.
Thanks for the help,
-Tony
Disable the software firewall that is showing the dialog. The dialog isn't OkHttp; it's just a side effect from OkHttp using your network.
Seems the issue might have nothing to do with firewalls as I expected. I read there were issues with earlier versions of Java and even 8u25. I am using 32-bit 8u45 a security patch release. I installed 32-bit 8u60 EA and it seemed to have fixed the problem. So I am sure 32-bit 8u45 has the issue. Hopefully when 8u60 is released (soon I hope) it will still have the fix. I will check another laptop I have that works to see what version of java it is running.
Regards,
-Tony
I hope this is not an incredibly stupid question.
According to what I can find online, it seems forking was added to GitLab in version 5.2. However, I can't seem to find in trace of it in the web UI. Or the help files. Or much anywhere else.
Is this perhaps a premium feature or something?
Or should it be activated/enabled somehow?
Thanks.
Also a side-note, if you haven't committed any files yet, fork option will not show to other users. you need to at least add a readme file in order fork a project.
The scenario : you have a main project at startup phase and multiple developers will be working on it. You created main project in root repo, logged out , logged with your user to for project for initial set up, fork option is not there.
Ok, I was being an idiot (sort of).
Seems if you login with a DIFFERENT user (i.e. a user who is NOT the owner of the project), the fork functionality shows up clear and plain.
Excellent then.
Props to the GitLab team - loving it!
I have somehow got into a strange situation with my CRM system.
A plugin I have developed is not getting updated correctly when the solution is imported. When I choose to maintain the customisations the plugin updates dont get applied, but when I choose to overwrite customisations the steps get doubled up and so the plugin gets fired twice.
Has this happened to anyone else? How do I stop this from happening?
Thanks
I've had a similar situation where I had plugins registered twice after importing.
I believe the way I solved this was:
Use the plugin registration tool to remove the plugin from the server you are deploying to.
Reimport the solution.
I can't see you doing any major damage here, but I would suggest backing up the server first because I'm not 100% on this one.
Are you assigning a strong name to the assembly? I've seen this kind of thing happen in CRM 4.0. If you don't assign a strong name with a key, CRM doesn't seem to see that it is the same assembly.
If you deploy the plugins using the plugin registration tool, solution deployment will duplicate all of the steps as it does not recognise the deployed plugin steps as their ID is changed.
If plugin assembly is deployed without the steps, you've forgotten to add the steps into the "Sdk Message Processing Steps" section of the solution.
#JamesWood approach will always work but is very heavy handed for a production environment, an IIS Reset and restart of the MSCRM services (in services.msc) usually clears any cached plugin assembly, while a redeployment should only be needed/used in dire situations.
On our Trac system, two things suddenly stopped working. The first thing is the update of the "Browse Source". The second thing is the auto-fixing feature. The only solution for the first issue is to manually run the post-commit hook of the SVN repository. But than we still have the problem, that Trac doesn't close ticket anymore depending on the SVN commit message. That was working before without any issues. Ah and a third thing is that PNG images are no longer shown in the HTML preview. The user has to download the file to see it.
Is there any known bug or issue for our described problem. Or how can I update the Trac system without loosing all the information within the Trac projects (I have set up a multi project Trac system).
If all else fails, reboot the server :)
Can you give us some more info about your server and Trac setup? For example, OS and version, Trac version, plugins used, etc.
It's odd for things to suddenly quit working. If you are running a Linux system, it's possible that your server installed some updates that your system isn't fully compatible with (for example, upgrading Trac can cause some plugins to quit working properly). Check your server's logs to see if anything was updated or reconfigured around the time Trac quit working.
Also, try setting Trac's log priority to 'DEBUG' and see if the Trac logfile contains any useful error details.
The solution was the following: file permissions!
To solve the issue we used the sudo in the post-commit hooks of SVN like the following:
sudo /usr/local/bin/trac-admin /var/trac/reponame/ changeset added "reponame" $REV
And we had to allow the SVN user to run the trac-admin command using visudo:
www-data,svn ALL=(ALL) NOPASSWD: /usr/local/bin/trac-admin
I'm working on a website with some other people. Usually when we want to modify something, we do the change on our machine and just upload the new version with ftp, hope it'll works (or that nobody will notice it doesn't the time we correct it) and that's it.
It's already not the best way to work alone but even less to work collaboratively so I'm asking advices.
I think that a solution like svn/git/mercurial could help me. I found bitbucket which allows free private repository with mercurial. But still after, how can I upload the changes I did to the ftp and make sure the version I've on my computer is the same than the one on the server.
We are all doing it during our free time (not paid) and some people comes and leave every year so I'm looking for something free, easy to use (explain to everyone why we should use a DVCS is already hard) and which doesn't rely on a specific person.
The server we are using to host the website is a cheap one and doesn't allow the use of ssh, svn,...
Thank you
Version control will not help with the issue you are describing - namely, uploading untested changes to a production site.
What you (and your team) need, is better quality control procedures - you need a test website and a tester (QA) person. The process would be:
Make a change
Update the test website
Have the update and the whole website signed off by QA
Update the production/live site
What you will gain by using version control (CVS, SVN, Git or anything else) is recoverability - you will be able to go back to a version before any breaking change. It will still not solve the issue of "the new code broke the site".
You want scheduled releases.
Commit and update code regularly
Code freeze or develop in a branch and merge to the trunk
test on a staging environment
Find a bug goto step 1
Release
You need to understand that what represents your latest correct working build is not what's on the server but in your source repository whether that be SVN or just the file system. Anything as long as it isn't the live server! Make sure everything works locally as expected then unless the site is huge (I guess not given your situation) deploy it in its entirety as a single version.