I've a multiproject trac setup that works perfectly for any single project, intertrac links are fine too. My only problem is that my users have to provide their preferences for every project. Is there an easy way to get around this and have user preferences shared among projects?
thanks, Viktor
You should take a look at the TracUserSyncPlugin that promise just that. Currently it's marked "beta" and "unfinished", so you may want to join in for more development, but at least you'll have a starting point.
There's not an easy way to do this that I know of. However, user preference data is stored in the database so it should be possible to write a script that synchronizes the preference data between the different databases.
Related
I'm working on a project with several developers and I need to systematically inform them about latest changes.
Any solution?
There's only one solution no matter how big is your project and how many guys are involved in.
It is called VCS (version control system).
I highly recommend you to use service like GitHub or BitBucket to have access to your code repository from all over the world. You can create a private repo and add your friends as collaborators, so only these people would have access to code.
Hope it will help.
we are starting to use Sonar. We want to use it for many different projects. Is there a way to give a project automated defined project permissions (for example with a name pattern). We found only the way to create a default template for new projects, but with this template every project would have the same permissions and we would like to give them permissions based on name patterns...
Do you know if there is a way to do this?
Thanks and regards
This is not possible yet - as of SonarQube 4.0, but will be soon: feel free to watch and vote for SONAR-4535.
I created a time recording program in vb.net with a sql-server as backend. User can send there time entries into the database (i used typed datasets functionality) and send different queries to get overviews over there working time.
My plan was to put that exe in a folder in our network and let the user make a link on their desktops. Every user writes into the same table but can only see his own entries so there is no possibility that two user manipulate the same dataset.
During my research i found a warning that "write contentions between the different users" can be occur. Is that so in my case?
Has anyone experience with "many user using the same exe" and where that is using datasets and could give me an advice whether it is working or what i should do instead?
SQL Server will handle all of your multi-user DB access concerns.
Multiple users accessing the same exe from a network location can work but it's kind of a hack. Let's say you wanted to update that exe with a few bug fixes. You would have to ensure that all users close the application before you could release the update. To answer you question though, the application will be isolated to each user running it. You won't have any contention issues when it comes to CRUD operations on the database due to the network deployment.
You might consider something other than a copy/paste style publishing of your application. Visual Studio has a few simple tools you can use to publish your application to a central location using ClickOnce deployment.
http://msdn.microsoft.com/en-us/library/31kztyey(v=vs.110).aspx
My solution was to add a simple shutdown-timer in the form, which alerts users to saving their data before the program close att 4 AM.
If i need to upgrade, i just replace the .exe on the network.
Ugly and dirty, yes... but worked like a charm for the past 2 years.
good luck!
I am in the process of building a completely fresh version of an application that has been in existence for a good many years. I can look back with horror now at some of the things I had done, but the whole point of life is to learn as we go along. The nice thing now is that I have a clean slate from which to work, and it's because of that that I thought that I would seek some advice from you all.
User settings are great for those things that each individual user would naturally want to and ought to be able to change, a theme or visual style for example. Application settings should quite obviously apply to the entire application irrespective of whoever uses it.
Somewhere in the middle though are a set of settings that I would like to give the system administrator the opportunity to change (default work periods, appointment time slots, the currency the company wants to use as its main trading one etc etc). These can't be user settings because individual users should not be able to change them, nor should they be application settings because I as the developer have no idea what the end user (or to be more exact the senior end user) would want to set them to.
Many years ago I might have considered writing such settings to the registry, or an ini file. I could perhaps (as this is an application that is tightly integrated with its own custom database) create a one off settings table, and read in the relevant settings at program startup. I could perhaps opt for a separate 'universal settings' xml configuration file stored in the all users directory. Clearly a number of options.
What I would like to try and establish though is the most efficient way to approach this. What is the best trade off between file read and write operations as against reading everything into a set of public constants at application start-up? These are not going to be settings that will only be referred to occasionally so efficiency is going to be key.
Just so that there is no ambiguity as to what the application will be. Traditional winforms, using vs 2012 as the development ide and vb.net as the code base based on .net4.5 and ef 5.0. Backend data to be stored in either sql express or full sql server. Target operating system for end users will be windows 7 or above (so due respect for the uac will be required).
I'd welcome any suggestions that you might have.
I'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.
A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.
I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.
This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.
If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.
Is there an issue with having only one installation of your program? Is it particularly large, for example?
Do you require admin privileges to run your program?
If not, odds are you don't need the Program Files folder.
I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.
If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.
Edit: Just saw your last sentence. ClickOnce can force the user to update.
A couple of things:
If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.
We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.
Cheers !
Edit:
Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.
A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).
One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.
You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)