I have been trying out Redmine to see if I like it better than mantis. However, I am wondering if it possible to modify watchers of a bug after bug creation. As a project manager, when I create a bug, I can select users to have watch a bug, but after I create it, I don't see a way to edit this list. Does Redmine have support for modifying the list of users watch a bug? If so where?
Of course you can edit this list - if you have the necessary permission, there should be the list of watchers at the right hand side of the issue's detail page, with a link to add watchers opening a dropdown list.
Related
I'm working on a SharePoint 2010 project. We have a usercontrol to include all of our custom javascript. I popped an alert in there whilst debugging something else, and lo and behold the alert was called twice. I checked and the file in question is included by only one Elements.xml file in one feature. So how can this be? I've tried searching the whole solution, and I only get one hit, so I must be missing something.
EDIT:
This is the code calling the User Control:
<Control Id="AdditionalPageHead" Sequence="10" ControlSrc="/_controltemplates/company/UCLoadJS.ascx" />
This code is found in the Elements.xml of the MasterPages folder, which deploys our custom master page.
Having searched the whole project for UCLoadJS, I cannot find another instance.
I think you have hidden WPs loading these Controls.
Try creating a new page and add the Visual WP once and try again
I know that this question is 9 years old but I just had the same problem, so in case someone stumble across this thread, maybe this will help you:
try to list all your delegate controls. you can slightly modify the script provided by Waldek Mastykarz : Checking which Delegate Controls are activated on your site
if you find duplicated controls (and that was the situation in my case) then its probably because you deployed your control using one feature scope (Site for example) and then redeployed with another one (Web). Follow the steps below to solve the problem:
1). switch to another feature scope (the one you no longer want to use)
2). deploy the feature
3). deactivate it
4). switch feature scope to the required one and redeploy it
Source: SharePoint delegate control is rendered twice
I'd like to use the roles and membership ability of Orchard CMS to limit access to a staff portal in Orchard CMS. At present there doesn't look like there's an out of the box way to do it.
I've found numerous references to modules that should be able to help out but none seem to work.
Very Simple Permissions is a codeplex item suggested by some that has a dead link nowadays and doesn't seem to exist on codeplex.
Science Project: Quanta destroys my site everytime I try to install it with a missing dll issue, and not sure if its what I need anyways.
Does anyone have any guidance as to how to either: show/hide menu items based on roles using the standard menu system or advanced menu plugin
or
limit content visibility based on roles. If its a module fantastic, otherwise don't mind getting my hands dirty with some coding but a point in the right way to do this mvc style would be great. I'm going to presume I need to edit the controller for the menu module to check for current membership and adjust the view data accordingly. I'm moving away from webforms. slowly. Still getting my head around the framework.
Thanks for checking in.
For those who are still struggling with this, there's a module is called ContentPermissions which is available here:
gallery.orchardproject.net/List/Modules/Orchard.Module.Orchard.ContentPermissions
Once installed, you can then add the ContentPermissionsPart to the Content Type you want to secure.
Quanta really is what you want. You are probably missing one of its dependencies. Pete, the author, is also super-active on the CodePlex forums so if you ask there, you'll get an answer.
UPDATE: Orchard 1.5.1, the current version as I'm writing this update, supports content item permissions and menu trimming out of the box.
When I deactivate a feature, or even just after removing a Solution package, I can still choose to select the Master Page which belonged to the feature I removed. This is a problem for me.
The only way to get rid of the hanging reference is to open SharePoint Designer and to browse to the sites _catalog directory then remove the .master files from the masterpages directory.
Is there a way to cause different uninstall behavior which would remove the hanging reference? If so how?
Thank you,
Yes deactivating the Master Page feature will not remove the master page from the Site you need to do it manually or using some feature receiver code that hooks the deactivating event.
My MOSS is a bit rusty, but can't you write some code in the
feature_deactivated event?
Do a manual remove of the master page there?
We are using the default Task list from a Team Site and would like to only allow those that the Task is "Assigned To" to edit the tasks. How do you go about enforcing this?
When we tried the "Advanced Settings", we found that "Only their own" meant only those tasks created by the current user.
It looks like you need to create an event handler that updates the permission on the Task everytime the assigned user is changed.
Quite a few people have had this problem in the past.
Check out this site for an example of the problems people have had. That said it should work out-of-the-box if you copy content when setting up the Task List.
Looks like, an event handler is the way to go. I found this page in some of my searching and it explains a lot of the problems related to this issue:
Email Notifications and Alerts - Sharepoint Tasks List
Unfortunately, the client wants no custom code and wanted SP Designer workflows and browser based customizations only...
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.