Workspace/Project Administration Features

Hello guys,

Speckle is becoming more and more a mature platform. With size/amount of data/users there is a requirement for order to not become too messy. We have encountered on our own deployment project duplicates as a result of project members not speaking to each other.

Additional issues which do not require a separate post …

  • not using the company-wide project naming convention
  • not using the correct privacy settings.

Speckle currently allows users to create infinite projects with the same name. Something, which does not fit when you want to use it as a platform for projects and not just a quick data exchange service. This is especially important in case one wants to reuse data beyond the usual shortterm use … say data extraction of multiple specific projects

here comes the addition to the wishlist:

  • Speckle should allow for specific project naming conventions (inside of the workspace to fit with the approach of selling the plattform). Naming conventions can be set by the admin as fields … Teams manager is a good example for how to do it right Microsoft Teams Management - Solutions2Share)
  • Projects should be unique in their number and people are not able to create duplicates - a check to prevent users from creating a duplicate
  • Admins should be able to define a template structure for projects … main folder/sub folder/Model (server Level or Workspace level)
  • Privacy Settings should be posed on the projects on admin level (Example: Projects should be private by definition of the admin … a global workspace/server setting posed on the projects)

I hope it is clear what I mean … if you want to talk about details I’m always up for a call.

Best,
Alex

Hey @AlexHofbeck. Great feedback, thanks!

  1. Naming convention. What’s a naming convention you would follow?
  2. Duplicated projects. I’m not sure we can check on anything else than project name. Do you have other ideas?
  3. Template structure. We hear you! Already on the list of ideas.
  4. Privacy settings control. Also something we’re hearing more and more. Also with the launch of workspaces. One setting we’ll be adding (TBD when) is giving workspace admins control over who can edit the privacy settings on projects.
2 Likes

Here some additions hope this helps :slight_smile:

1. Naming Convention
It depends on the firm and how they do it in our case it is like this …

FRA24 P001 - Name

FRA = Frankfurt … can be VIE, BER, PAR
24 = year
P/C = Project/Competition
001 = running Number
Name = Freetext

In the Teams Manager for MS Teams we can define fields in the admin settings. Those fields can be of type number, dropdown, string …


When users create a Teams team they have to fill out the mandatory fields.

Autodesk is less customizable … there it looks like this

2. Duplicated Projects
FRA24 P001 - Name

In the example above … the app creates this as identifier “FRA24 P001” … if this exists it does not allow it.
Example: [FRA24 P001] - (Steel Framework) vs. [FRA24 P001] - (Steel-Framework)
Two identical identifiers therefore the second project is not allowed to be created

Project numbers are a standard as far as I have experienced. Does not matter if it is a small firm or a big one.

2 Likes

There could be an additional “project code” field that is unique, I think most organizations have something of this sort.

When creating a new project, we could suggest reusing a project with a similar name (like discourse does)

1 Like