Hi again. So my next newbie questions are on the concept of streams, branches etc.
1- Is there anyway to assign metadata to streams other than name and description? My concern is after a while the user can end up with a whole lot of streams on their list which they can’t easily distinguish to which project they belong. Stream names similar to: “Initial design”, “Structural studies” etc can exist for multiple projects. Of course we can include the project number or name in the stream name but that’s going to create another naming convention in the office that people have to remember (ie forget). Would be great if the user can assign projects and filter/group streams by that. Or admins can later assign streams to projects.
2- If I understand correctly, in Speckle, “branch” is like a new folder to put data to. It might be the use of git icons that’s confusing here. But as I understand it the branch feature is not to be used for things like a new design option based on another branch similar to creating a new feature for a software in software dev world? ie you can’t create a branch based on an existing branch and then merge back into it when you’re satisfied your changes are good. Also concepts like rebasing, cherry-picking, diffing etc don’t exist in Speckle, right? - okay just read more about this here and it seems like we’re not quite talking about duplicating git functionality here. Question now is, are some of the git features possibly on the roadmap?
I think the answer to your needs here would be having the concept of “Projects” as collections of streams. This is probably the only feature from v1 that we haven’t yet brought to v2. But don’t despair, it’s on our backlog! Would something like tags or the possibility to star/favorite streams be helpful too?
you are correct, branches can be seen as “folders”, or collections of commits. Currently we don’t have features that’d allow you to merge the contents of two branches, cherry picking or rebasing. We will definitely add some of these in the future though, probably in a simplified way than what git does. What you can already do, is use the desktop connectors to manually “merge branches” or “branch off” existing ones. So you can definitely use branches to store design options, it’s just that currently you’ll need to handle their content form the connectors and not from our Web interface. To start, we have recently enabled the possibility of loading multiple branches/commits/objects in the viewer.
Hope it makes sense! Happy to discuss more in detail
I think the answer to your needs here would be having the concept of “Projects” as collections of streams. This is probably the only feature from v1 that we haven’t yet brought to v2. But don’t despair, it’s on our backlog! Would something like tags or the possibility to star/favorite streams be helpful too?
Yes to all but collections/projects would be of higher priority for me.
What you can already do, is use the desktop connectors to manually “merge branches” or “branch off” existing ones. So you can definitely use branches to store design options, it’s just that currently you’ll need to handle their content form the connectors and not from our Web interface. To start, we have recently enabled the possibility of loading multiple branches/commits/objects in the viewer.
By handling it from the desktop connectors, you mean creating an empty branch, receiving the contents of another branch and push it to the empty branch, right? Also is the latter, using custom code or is the functionality already implemented in the default viewer? [oops! just refreshed the page and it’s there now! ]
I was wondering what the status is on the “Projects” concept being integrated in v2. We need to send an entire project in multiple streams from GH to Revit for drawings. As you might be aware any time you send new objects your annotations dissapear, so we thought we need to split up the objects. That’s also why I’m currently being added to about 50 streams by hand. It is quite cumbersome, haha. (Maybe for another feature request: mass adding of collaborators)
Hey Wes, Projects are indeed coming - expect an announcement sometime soon on our new frontend!
We’re not adding a new entity though, we’re renaming Streams to Projects and Branches to Models.
The new branches/models will allow infinite levels of nesting (they already do, but it’s less obvious) wich should resolve your organizational issues.
The applicationId seems to work!! Thanks a lot, this will really help us save A LOT of time redoing our drawings.
Our current workflow is completely parameter and GH driven, no more manual modelling in programs like Revit or any other FEM/BIM package. Either using Speckle or program specific GH libraries (like with SOFiSTiK or Tekla). In addition, we’re now getting towards the stage of approaching design as a software development project and trying to automate most of the boring stuff in the design process.
We’re now getting to the point where we’re generating so much data that we are struggling how to communicate it the client. Design parameters, output models, output section drawings, quantities etc.
This could already be possible, but when I think through the idea of a single stream for a project, and leveraging layers of nested branches to separate models ( disciplines, teams, consultants, use cases, etc) we would need the ability to programmatically and manually apply permissions to each branch/sub-branch.
Yes, permissions are currently only set at a stream level.
We know that more granular permissions are needed to help the rollout of Speckle in large organizations, so this is definitely on our roadmap!
Do you already have an idea @michaelgmccune of an ideal set up?
I can think of:
setting permissions on streams and branches
assign permissions to users or teams (groups of users)
ability to have permissions for read only, read & write, admin, and admin only on sub folders. This would allow some teams to only pull down/query for reference and other the ability to push/write. Only a user acting as a manager needs to have admin rights on higher level branches, but teams should have admin rights on sub-branches so they can create and manage their own branches at a specific level determined by the organization.
ability to assign users and teams the permissions above on streams and branches.
