Submit Your Suggestions for Viewpoint Team

Any update from Viewpoint on this? I believe the issue is best resolved by ability to customize existing "roles" by allowing simply "read" or "write" access at each module and each document folder and then allow application of folder permissions by GROUP versus contact.

We are a subcontractor, the names of the collaboration types don't make sense for what we need.

Yes! I agree!

We need the ability to completely customize the collaboration types/roles. We are a subcontractor, so even the names of the collaboration types don't make sense for what we need.

We have General Managers that need access to view everything, but don't want or need the ability to delete anything.

We would also love to be able to add the General contractor to our system, but there are no permission levels that achieve what we need.

Our Foreman need the ability to view everything, whether it is public or private, but we can't give them permissions above Superintendent, which means that everything we create must be made public in order for our field to view them. And there is no ability to make everything Public by default.

The only way to achieve making every GC/Sub that uses VP Team happy, we need the ability to customize collaboration types ourselves.

Please see this suggestion to add security groups to the document structure:

https://team.ideas.aha.io/ideas/VPT-I-1514

Any update on what is happening with security?

It would be nice if I could make a folder public but only limit certain roles to be able to upload to that folder.

I would like to see a project role or detailed security as well.  We have business partners, specifically Engineering firms that we want to upload drawings, but don't want to give them the ability to edit or delete work items.  

We just ran into this issue this morning. The fact that Superintendents cannot markup drawings is not helpful. Our Supers need to be able to mark up drawings without having such a high level of access.

Any updates?

Now that Viewpoint has provided Multiple Role Types with their own set of permissions we have a lot of choices for access types which is good, problem is very few meet the access criteria we are looking for. It would be great if each role access was customizable. 

This has been brought up again by multiple Project Owners.  Since we cannot use the Drawings module (issues with file naming and collaborators not being able to upload drawings) we have to use Documents.  We do not want our Trades (Subcontractors) to be able to upload or edit drawings (they can also restore files) in folder we have in Documents, but can't make them Project Reviewers as that will prevent them from being assigned a Submittal.  

We need to be able to make some folders read-only yet still let them Collaborate on RFIs and Submittals.  

R10 has been released with this feature but doesn't address my issue.  All Project Roles (Manager, Editor and Engineer) have access to all documents and can even change their own collaboration types.  If I make them say a Collaborator, the Documents issue is addressed but now they can't enter a Submittal.  

Any progress on this request?

That's hugely helpful! I misunderstood that during today's implementation training. Thank you for explaining it.I know you mentioned working on the permission controls mid-march. How long do you think it will take for security groups to be developed?

Parent folder access is not required to view a child folder.  Let's assume a structure like this.

• Folder 1
  • Sub Folder A
    
  • Sub Folder B
  • Sub Folder C 
    • Third Level Folder
      

Today you can add a user directly to 'Third Level Folder' without any other permissions.   When they login, they'll see just enough of the parent folders to navigate the hierarchy, but won't have access to it.  (Not quite how VFP handles this where you can hide structure with virtual containers)

A user added directly to 'Third Level Folder' would see this in their tree.  

• Folder 1
  • Sub Folder C
    • Third Level Folder
      

The user added to 'Third Level Folder' would not be able to see any documents or other folders in 'Folder 1' or 'Sub Folder C' we simply just give them the breadcrumbs of where their folder lives (as many times this provide context to the document).  

I understand your approach. And simplicity is always a plus. I am confident that you and your team are making efforts to strike the difficult balance of simplicity and functionality. To my understanding, parent folder permission is necessary to view a child folder. However, parent folder permission currently grants access to all child folders, thereby negating the ability to deny access for a user to select child folders; if I am correct in my understanding, this is a problem and forces the creation of more parent folders in order to properly apply appropriate security.

Hi Mary,

Unfortunately having our Owners as Project Reviewers works with Documents but doesn't give them access to see any Submittals or RFIs unless we CC them on everything and they did not want to be inundated with hundreds of emails.  

Max, there are definitely some things from VFP we want to bring over.   Team is being built ground up, and one of our key tenants is simplicity/ease of use.  So we're started rather simply and are being very thoughtful in how we add complex items to Team (like hierarchal security) without over complicating the system.

That being said, you can already control users security at whatever level folder you'd like. You can add a user to the 3rd level deep and they wouldn't be able to see any items in the parent folder.  However you can't override their security, so if you add them to a top level folder, you (currently) won't be able to over-ride that inheritance down below.  

We're working on a couple things to make this a bit more obvious, in the near term.  But today if you can edit a child folder by selecting it in the grid (while you are in it's parent folder) and choosing edit from the ... menu.   From there you can add users who you only want to have access to that folder and not the parent.

Really looking forward to that Josh. This is a make it or break it feature for our organization. I would really encourage you to visit your Viewpoint for Projects (VFP) platform. Security there was really set up well. Enterprise admins had the ability to create security groups and then use a project template to create security groups per project. Also, the parent and child folder security is more practical than the current team structure. A user could be granted security group specific access to each child folder, independent of the parent folder permissions. This is very helpful because it allows for a logical grouping rather than a grouping dictated by security measures.