I'm working strictly in Office 365 online. I have created an MS Team, which has automatically created an SP Team site. I created a new list on the SP Team site. I need members to only see things that have been assigned to them, which ultimately means I have to prevent them from being able to create or edit any views. In the SP site associated with the team, I changed the permissions for the edit permission level associated with the members group so that they can't create or edit views. Signed in as a member, and I can create and edit views. Any ideas? Is Teams overriding what I'm trying to do?
Leave the original permission levels as they are. This can be done in the list.
There is an Advanced list setting to allow people to create new items and only read or edit the items that they have created. Go into the list settings, click Advanced, and turn on the desired setting.
This way, any view will show the user only the items that they have permissions to see.
Please following steps:
1.Access the SharePoint list as a site administrator
2.List settings >> Advanced settings
3.On the Advanced Settings page, scrollto Item-level Permissions section, check "Read items that were created by the user" option and "Create items and edit items that were created by the user" option
========================= Updated Answer ========================
Please following steps:
1.List settings >> Advanced settings >> (Item-level Permissions) check "Read items that were created by the user" option
2.Go back List Settings page, scroll to Views section, click on the default view
3.On the Edit View page, scroll to Filter section. Check "Show items only when the following is true:" option and set Assigned To is equal to [Me].
I edited the edit permissions for the site. I deselected "manage personal views", but as mentioned, it still didn't work. I had to also deselect "manage lists" permissions. It also does a few more things than disable view creation by users with edit permissions but I'm ok with that. But, now I can no longer see view creation or editing capabilities if logged in as a member with edit permissions.
I could have created a new security group, but in this case, just changing the edit permissions is fine. The solutions above would not work because I want people to only see what has been assigned to them by an admin, so it has nothing to do with who created the item. The default view says to only show items where the "Assigned to" field is equal to [ME] and this is the only view they can see and cannot edit it or create a new one that would show things they are not supposed to see.
I used Phrase lists in LUIS in the past. However, the entry is not visible in the left menu anymore even though the documentation says it should be there:
Open your app by clicking its name on My Apps page, and then click Build, then click Phrase lists in your app's left panel
Are Phrase lists removed from LUIS?
Please see this screenshot:
A recent fix was deployed. Please refresh the page
Is there a way to customize the "My Work" pane to show more groups?
For instance, I currently have In Progress Work, Suspended Work, and Available Work Items. I also have a "Code Reviews" section. How could I add a section for "Bugs ready to test" or something along those lines?
I ask this because I have work items in my queue that don't appear on this list - it seems as though Tasks do, but Bugs do not.
Thanks!
You can change the Available Work Items section to show the results of any query you want. Just create a query that shows what you're interested in, and save it in My Queries. Then in the My Work pane you can select it from the drop-down:
Is there a way to search for or filter changesets by user?
The History view seems very inflexible.
For that matter, is there a way to filter changesets by anything?
Can you see a list of your users under Team Members in the Team Explorer tab? If so then right click on a user and select 'Show Checkin History'. This will enable you to see a full list of Changesets checked in by the selected user.
There is also a "Find Changesets" toolbar button in the Source Control Explorer tab
I don't know how to search by user, but regarding the second part of your question about existing filters : when you're performing a search (right click "Find in Source Control") or a "merge up to a specific version" option, you can select to search by changeset, and then search for a range of changeset or a range of dates.
I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.
Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.
The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).
Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.
However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.
The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):
“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”
The Apple Human Interface Guidelines states (pg189):
“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”
In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.
As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.
BTW, what’s the difference between Add Catalog and New Catalog?
In general, it's a bad idea to have menu items accessible only through a contextual menu. Many users may not think to right click on an item to find out what actions can be performed on an item.
From your description, it sounds like it would make sense to have a 'Catalog' menu that disables menu options that are not currently relevant. For example, if no catalog is open, the 'Close' menu item would be greyed out. Similarly, the 'Open', 'Remove', 'Refresh', etc. items would be greyed out if no catalog is selected.
I suppose this depends on your user base, and who you're targetting your software at. Personally I wouldn't expect the user to be able to deduce what functionality is available when it is essentially "hidden" until they right-click on the correct item.
If it were me, I'd have a toolbar shown with the functionality exposed on there. By default the buttons would be disabled, and clicking on a node would enable the appropriate buttons based on the context. You could have this in addition to your current right-click options.
As a rule, I've always treated right-click menus as a redundant (i.e not necessary for operation of the software) shortcut to functionality for "power users".
I would leave the menu item out because the user doesn't have a way to see what catalog they are modifying if the treeview is hidden which can create problems if they think a different one is being shown.
Though, the accessible solution would be to trigger it with the keyboard also.
Yes. One key feature of UI is "discoverability": can the user find the function?
If you think that having a top-level menu doesn't make sense, based on the context, then you could have a menu button (scroll down) labelled (e.g.) "Actions" at the top of the pane.