I have just been tasked with overseeing an Office365 Sharepoint team site, and there is a very odd legacy issue that was left unresolved by the last administrator. We have the standard set of groups that you would expect to see (visitors, members, owners) and one of the folks here is in both the Members (contribute) and Owners (full control) permission groups.
However, her ability to access things is... strange. She can view most everything, and add new content to most everything (lists, forms, etc.) But she cannot edit any documents, list items, etc. Nor can she delete items.
Is there a way that her permissions (full control) could be in conflict with another setting? What should I look for to investigate further?
All help will be greatly appreciated, as this is quite mysterious.
Cross-listed at: https://sharepoint.stackexchange.com/questions/58306/permissions-issues-with-office365-sharepoint-owner-account
You want to look at the document libraries and lists in question, by default they inherit permissions but this can be changed. Select the library and select the permissions icon from the top ribbon to check to see what that particular user's rights are for the items in question.
Related
In Lotus Notes/Domino, we have the functionality of Readers fields, which I know all about. These say who CAN see a document. I would like to know if there is some way (may be undocumented) where you can have that type of thing that says specifically who CANNOT see a certain document.
We have an application for HR, and some of the documents in there reflect negatively about certain people (complaints, for example) and everyone who has access to the database currently can see every document. I would like to hide this type of document from that specific person. I have not enacted any Readers fields on any documents in question.
It would be really nice to have a way to keep that current setup, but insert a factor of who to HIDE the document from like Readers fields do.
I know there are undocumented features people have learned about over the years, and wondered if anyone knows of such a thing that I can use.
Create a role called [ReadAll].
Create a Group called HR Readers and one called HR Restricted.
Add the people who can't read documents to the HR Restricted group. Add all others to HR Readers.
Add these two groups to the ACL and give the HR Readers group the [ReadAll] role.
Add a readers field that is computed to "[ReadAll]" on the documents you want to prevent the people in the "HR Restricted" group to not see.
No, there is no feature that does what you want. Not on a user-by-user basis. You can play with groups and roles, as suggested by Rob Mason, but those groups and roles have to be pre-determined. We asked for Non-Readers fields (at least) 20 years ago so that we could do what you want, but Iris, Lotus, IBM, and HCL never did it. I presume that either (a) it's hard, or (b) there isn't enough demand. Or both.
To hide content from specific people, you can use hide-when formulas within a form. I.e., the hide-when formula on one or more sensitive fields would be set to
#isMember(#UserName; RestrictedUsers)
where RestrictedUsers is a field that contains the list of people who cannot see the data in the fields.
But this is not real security. A user can see the document in views, and can see the hidden fields by bringing up the document properties dialog, or with a tool like NotesPeek. If you're talking about a Domino web app, and users don't have Notes clients and you have strictly-managed desktops so you are sure that is the case+, then it kind of sort of works. Admins and developers, though, would probably have the clients and would be able to see fields in documents that they're not supposed to.
I believe if I simply compute a Readers field to say something like:
whoToHideFrom:="John Smith/org";
#Name([ABBREVIATE];#Username) != whoToHideFrom
I will try this and mark this as successful or not successful after I test it
Foreword: I've searched around on this question a fair bit and found answers which are close to a solution, but not what I'm looking for. So here I am, and I hope someone can help me. I'm relatively new to VSTS, so be gentle (or at least constructive) ;P
The Question: I'm looking for a way to restrict access to specific tickets (NOT by ticket type) that contain NDA protected data, whilst keeping them in the same backlog and iterations as the rest of the tickets related to a project.
We have many different NDA protected customers, so whilst creating a new ticket type per NDA, and restricting access to this, could work, it's not the solution I'm looking for.
Alternatively, I'm barking up the wrong tree, and there is an entirely different and "better way" to support this use-case?
Edit 1 - More info: Let's say I have 1 backlog for a product. It contains only 2 work items. It's important there is only 1 backlog for planning and overview by a product owner.
One of the two work items contains sensitive information only half the development team should have visibility to. How do I keep both tickets in the same backlog and iterations, but hide the sensitive one from some team members?
Thanks in advance for your time!
Regarding permission of work items in a team project, you can set the permission in area and iteration scope, but can’t for specific work items.
So, you need to put these work items in different area and manage permission for this area. Simple steps:
Go to team project admin page
Work=>Areas
Click New/New child, to create a new area.
Click …=>Security, set the permission for the group(s) or user(s)
Click the default team’s settings => Areas
Click + Select areas to add that area in order to show related work items (in that area)
I have a requirement to find a way to archive subsites from a site.
When I say 'Archiving' I mean moving a subsite from one site to another so the end users can still access the subsites and check the history etc.
The main site is a Training site and the subsites are training courses, when these courses have ran there is no need for them to be sat under the training department site and I can envision it becoming confusing with too many of these subsites.
I know I can move them using structure and content in site admin but don't really want end users to be doing that after each course has ran ( we have had over 500 this year!)
Has anyone else faced a similar issue or have any advice to how they would go about it?
Many thanks
Is there a need to retain the subsites? If so, instead of moving the site, perhaps changing the way your users access the sites would be an easier way. You could set up a list with the current classes (assuming you don't have one already) and include a field in that list that links to the course's subsite. Create a view that shows only the current courses so the end users never see the other subsites.
If you don't need to keep the subsites, you should look into some kind of workflow that can kick off when a class expires that deltes the subsite. I'm pretty sure you can't create a workflow with Nintex or SharePoint Designer to move a site to another location, so you may need to code something with C#.
In our YouTrack project all issues are historically visible to "all users" which is also the group with the same name that shipped with YouTrack.
Now we are adding new users with restricted permissions and they should only see a small part of the issues. They should start seeing no issues at all, and then single issues (old issues and new issues) should selectively made visible to them.
I tried different ways to make this happen, but without success.
1) If I create a group for them "restricted group" - then I can give this group permission to view issues. And then they can see all issues, and if I uncheck the "view issues" privelege checkbox, then they cannot see any issue at all. This does not help me, as they either see all issues or none.
2) I tried to change the "issues is visible to" field in a single issue and set it to "restricted group". But YouTrack won't let me, only "all users" or "project XY Assignees" can be selected here. Edit: this is still true, after I add myself to "restricted group", see Alex.V's answer to this question
So I deleted the group "restricted group" and tried to work with "assignees":
3) I choose an issue and set its visibility to "My Project Assignees". And then I add a user to the "My Projects Assignees" group. But now the user can see ALL the issues in that project. In the group settings I find out, that the checkbox "Read issues" in the definition of this group's role "Developer" can be unchecked, and this changes visibility. But again for all Issues! And it does not matter If I set the visibility for the issue to "My Project Assignees" or to "All users" - now the user can see no issues at all, after unchecking the checkbox.
This is YouTrack 4.2.2 (build #6029 [23-May-2013 18:30]
Please show me a way to selectively make issues visible to a group of users and invisible again. I know it is possibly quite simple, so what is my mistake?
In the meantime I was able to understand how the view permissions work.
The dropdown box at the top of the issue page acts only as a filter and you can only EXCLUDE users with this dropdown box that could already see the issue when visibility was still set to "all users".
So I think one way to accomplish what I want I will have to change all issues' visibility to let's say "admin1 group" and later switch only some of them back to "all users" so everybody can see those.
OK. I managed to achieve visibility with the help of the post in this: comment.
In reality it is pretty straight forward when you understand how the permissions work.
There are 2 "components" that take part in achieving this:
1) The issue visibility (visibility field on an issue which defaults to: All Users)
2) The project's groups/users and their roles.
I'll explain by example:
Step 1:
Create two groups: Managers and Developers and assign them to your project: Restricted Project (prefix: RP). Both have roles of developers, so that they can edit an issue's fields, comments description and log work. These 2 groups are the only groups in your project.
Step 2:
Say in your workplace you have 10 users: U1, U2, ..., U10
Assign U1 and U2 to Managers and Developers
Assign U3 and U4 to Developers only.
Step 3:
Create a new ticket (RP-1) and change the visibility of this ticket to: Managers
Create a new ticket (RP-2) and change the visibility of this ticket to: Developers.
Result:
With this setup, users U5-U10 will not be able to see the RP project or any of it's tickets. Doesn't matter which search they will perform.
Users U1 & U2 will be able see/read both tickets: RP-1 and RP-2
Users: U3 & U4 will be able to see/read only ticket RP-2
NOTE: If you create another ticket: RP-3 with visibility: 'All Users' then any of the users across all groups in the project will be able to see/read this ticket.
I hope this simplify things :)
As for your second variant, you can only choose a group you belong to in "issue visible to" combobox. Will this variant work for you in other aspects?
I am new to phpBB3. I have just installed phpBB3 on my localhost. I have gone through it. I am getting one problem that if I want to create two types of forum
1. Pre Sales which can be seen by any visitor or visitors who are logged in
2. Post Sales which can be accessed by only the visitors who have paid for that
please guys is there any solution for that?
For the Pre sales forum, you don't have to do anything special. Guests will be able to see that forum by default.
For Post Sales, you will create your forum, but do not copy permissions from any other forum when you do so. Then log into your Administrator Control Panel, select the Forums tab. On the left select Forum Permissions.
You have two options at this point. If you are placing users into groups, for example a customer group that can access Post Sales, you will use the Groups column. Otherwise, you'll be managing each individual user. I'm making the assumption that you will want to do this by group.
Select the group(s) you want to have access to this forum from the bottom right box. Click Add Permissions and they will appear in the upper right box. Now highlight all of them and select Edit Permissions.
From the next screen you can customize what they can('t) do on this specific forum. The easiest is to select one of the preconfigured options (Standard, Standard+Polls, etc), but if you want to can manage specific permissions as well.