SharePoint User Group UK

Hello

I've created a site (called Business Development) for project management and have a range of projects set up on it, each has its own subsite.  Each project subsite has a global task list.  Each task list has permissions that are not inherited from the parent site, because the only area that users need to actually change is their task information, none of the supporting project documentation etc.

My organisation has 2 project managers who are owners of the main site/subsites.

Each project has its own custom members list (called Project Team).

I want to be able to do the following:

• the Project Managers (owners) will enter a list of project tasks and assign them to Project Team individuals.
• the members of the Project Team will then manage all tasks allocated to them.  They should have permissions so that they can only edit their own tasks, not anyone elses.

This should be fairly straightforwards but somewhere along the line I think I've gone overboard with removing permissions. 

The problem I now have is that when a Project Manager adds a task and assigns it to a Project Team member, that person can't edit it.  I've been patching over this by giving people full permissions to the list, but this isn't ideal because it means they can edit other people's tasks too.

As a sharepoint novice, I thought I'd come ask the experts what permissions I should be checking for.

Currently the task list has:

• Business Development Owners- Full control
• Business Development Members - Contribute
• Business Development Visitors - Read only
• Project Team - Contribute
• (named individuals) - Full control  <- this is the one where I've patched over the problem

But it doesn't have approvers, designers etc. - I suspect I've knocked out a permission that's needed for users to edit tasks assigned to them, that they didn't create.

I've got approval and versioning switched off for the list and there's no workflow built around anything.

Can anyone spot the problem or suggest anything I might try?

Any help would be greatly appreciated.

Cheers!

I've recreated this issue with a similar setup and have so far managed to get it working.  The small differences I have for testing purposes is that the user was given direct contribute access to the list part.

So for example, I have full control, and user 1 has contribute access. 

I know it's probably not the answer you're looking for.

Another option which may or may not help, you could filter the view so that it only shows tasks assigned to the logged on user?

Sorry I can't be of any more help.

sbrandom wrote:

I've recreated this issue with a similar setup and have so far managed to get it working.  The small differences I have for testing purposes is that the user was given direct contribute access to the list part.

So for example, I have full control, and user 1 has contribute access. 

I know it's probably not the answer you're looking for.

Another option which may or may not help, you could filter the view so that it only shows tasks assigned to the logged on user?

Sorry I can't be of any more help.

Thanks :o)

I've already got the filtered view as you suggest, each user gets their own page of indicators and tasks, that works fine.  They can view no problem and they get the menu options for editing, and can actually open up the task for editing, but when they try to submit their edit they get an access denied error.

Which is very strange.

I think I'll try setting all users to inherit permissions from the parent site and just giving the project team contribute settings for the site overall, and see how that works.  If I can get it to work that way then I can break off the inherited permissions again and switch them off one by one until I find the one that's caused the problem.

Are you inheriting the groups from Active Directory? There have been problems with MOSS when the groups are inherited from AD.

Cathy

 

============

---

Cathy Ward
SharePoint Consultant
Converge Point - SharePoint Consulting Services

ConvergePoint wrote:

Are you inheriting the groups from Active Directory? There have been problems with MOSS when the groups are inherited from AD.

No, they're groups I've created in Sharepoint.

I tried resetting the subsites by resetting their permissions to inherit, this didn't fix the problem.  I also tried then ticking the "Approvers" option to the task list, this didn't help either.

*scratches head*

I have the exact same problem right now. I can't fix it. Anyone ever figure this one out?

Any info would be greatly appreciated.

 

-Drowning in MOSS.

Still not fixed, I have to fudge permissions by giving everyone full control.  It's a real pain because I have two project managers complaining at me regularly that the system isn't working as intended.  I tell them they have audit trails etc so they can see who messed up, they get alerts of all changes etc, but they're still right in what they're saying.

We've done the same thing -- gave full control permissions on the list. We've set the list options to only let people edit their own tasks. We haven't done a lot of testing yet -- every day we're wasting time fooling with permissions and issuing new tasks -- but we're hoping that limitation helps control the list. Maybe we'll find out tomorrow that it's useless! :)

Thank you for replying.

I'm going to keep digging on this and will post anything I can find.

one question...did you get your task list from a site or list template?

we have one task list operating as it should -- site members with contribute can edit items that he/she is assigned. they get their email, they can edit and save. i believe that site was created out of the box from the plain sharepoint team collaboration site.

the site where its not working is from a template we created (same team site, but with some look and feel customization). we feel that somehow permissions from this template site are carrying over. where, we have no clue! :)

Binky wrote:

one question...did you get your task list from a site or list template?

we have one task list operating as it should -- site members with contribute can edit items that he/she is assigned. they get their email, they can edit and save. i believe that site was created out of the box from the plain sharepoint team collaboration site.

the site where its not working is from a template we created (same team site, but with some look and feel customization). we feel that somehow permissions from this template site are carrying over. where, we have no clue! :)

My sites are created from templates too, so this sounds like you might be on to something!  If you can figure this one out please post here to say so, I'd love to be able to fix this one!

my small SP group continues to struggle with this. 

as for my idea with templates -- i have to do more testing. i can't say for sure what is happening. i wasted so much time fooling around with permissions, and changed so much, i'm not sure anymore where we started. one site's task list would not send out emails, no matter what we changed. the site was made from a template.i found a working task list on another site - one made from the out of the box team collaboration site -- and made a template out of it. i went to original site and created a new task list based on template. now it sends out emails. i'm afraid that every site we made from the template is going to have a screwed up task list, and who knows what else....the email problem is different from the permission problem...

i don't see this in your original post -- if i missed it somewhere sorry -- we did discover this way too late. it seems that SharePoint doesn't considered an assigned task to be owned by the person the task is assigned to.

you can leave your users with contribute -- its enough -- but the list settings have to be set to let them edit all items (not just their own). the user can then edit his/her own task with contribute.

for us anyway, when you set it to only allow the user to edit his/her own items -- its limiting it to the person who assigned the task!

for example... binky assigns a task to michael. if the list advanced permissions are set to allow users to only edit their own items. michael can't edit his task because sharepoint thinks its not his -- its binky's because binky created it. only binky can edit that task. change it to edit all items, and michael can edit his task (binky's item.)

i feel like we must be missing something here because for a task list, this is ridiculous. maybe something is wrong with our environment. we've wasted the better part of several days on this and we have to leave it at that for now.

 

 

 

Yes I've got the same issue where Sharepoint is acting as if the task belongs to the person who created it, regardless of whether they assign it to someone else.

I hadn't tried using contribute/enabling users to edit all items rather than just their own - I guess this would be better than full permissions because they can do less damage that way so I'll try that, but it remains a frustration and is unlikely to appease the project managers involved, because users can still potentially delete/edit other people's tasks.  Surely the assignee should be allocated permissions to a task... it definitely feels template related but trying to pin it down is virtually impossible - in a live environment especially where people expect a working product....  the problem I have is that the initial test site, our prototype, worked, and was then used to create a template from which a dozen or so project sites were created... and it wasn't until a few weeks in that these problems started showing themselves once the projects were under way and lists of tasks were assigned by managers.  At that point it becomes too late to rebuild the whole site, it's gone live..  and so you patch things over by fudging permissions, and end up as you describe it with lots of different sites on which you've tried lots of different ways to make it work, all of which have slightly different configs.  I haven't managed to get any of mine working at all since the prototype site, which is why I think you're probably right about templates not carrying over list permissions properly.

Sidenote but related: It's definitely the case that at one stage templates didn't carry list views across properly, although that was resolved in a hotfix apparently...   I've not had cause to create a new site from my templates since Office SP1 was applied to the server so I don't know if that's going to be resolved now, in the past each time I've used a template to create a site I've had to pick through all my views/KPIs etc to set them back to the correct view.   So if MOSS misses (or at one stage missed) view configurations during site creation using a template, it's not beyond the realms of possibility to assume another quirk of templates might be botched permissions on tasks lists. 

wrt email, I haven't set up any of my task lists to use email, although a couple of them have alerts set up, but these alert the project managers who have full permissions to the lists anyway, so not sure whether that proves anything either way in my case.

geez, this problem for us gets worse every day.

here's a warning for you...

if you happen to allow multiple choices in the "Assigned To" column -- you can't use the auto email alerts. the thing goes haywire. our managers specifically asked that we change the column so that multiple people could be assigned one task.

well, when you do that, and a user edits his/her task -- all sorts of random people from AD start getting their names added to the email list for the task. the email reads that the task has been "Reassigned" (as opposed to "Changed") with original text and names all stricken-through. just a complete mess.

of course i was instantly googling and found that this, too, is a known bug. wonderful. i love having half the office come up to me with their blackberrys filled with crazy tasks completely unrelated to their jobs. wtf??

the hotfix was sort of buried  and i don't feel comfortable trying to implement the fix just yet. i'm a newbie, i've only been doing this a couple of months.

 

 

There actually seems to be a workflow - or at least an "event listener" - on the task list; it's just hidden.

Whenever that is the case, and you create a template, you must save the list (or site) using the "with content" option, or else the workflows / event listeners will not get saved.

That said, there are plenty of reported problems with templates containing those - it's definitely much safer to create the site (or list) from its definition, as many have already pointed out in their replies. The out-of-box site definitions can be copied and then modified to suit different needs; but this is a task that needs development skills / knowledge (although not necessarily any C# programming; most of the definition is in XML files).

Cheers,

Pauli