Globals speckle new UI

Help
1

Hey!

maybe i missed something, but where are the ‘Globals’ in the new speckle UI?
I can still see them when i login to the old interface, but in the new one they are not present

1 Like
2

Globals is not yet present as a UI in FE2. The branch/model name remains “special” and protected, but the interface is under heavy review.

3 Likes
3

Hey @Jonathon any update on globals?

Looks like you can’t create globals model in dashboard but can via a connector – is there anywhere I can follow the proposed changes to the globals?

1 Like
5

Hi Luke! Here is a good place as any to follow updates on this.

As a quick heads up: globals as you know them will not be coming back - the whole secret protected branch way was a POC. We’re planning to bring them back as customisable metadata on any top level entity, specifically projects and models (versions too if there will be a usecase). These will then be exposed via the api, of course.

We’ll most likely be able to start working on this sometime in (late) summer.

We’re obviously curious what you’re using them for, so if you want to tell us your usecase, we’d be very greatful!

4 Likes
6

Sorry for slow reply @dimitrie. Only returning back to Speckle after mostly ignoring it for the last 8 months - globals were handy for setting project information, is good to hear they aren’t disappearing completely.

Having access to project metadata is nice for mapping to document user text in Rhino or Revit Project Information – especially for consistency of template variables (i.e. in drawing sets), or displaying on a dashboard, but I’m sure that’s obvious.

Happy to explain further if you’re interested.

7

@dimitrie just wanted to add a further thought about metadata.

Something I’m grappling with is linking projects together – say I have a client that has repeating projects, maybe they’re developments or a bunch of interior fit-outs. At the moment I’m not sure how I can query Speckle to get all projects for a particular client, besides storing a reference for client_id > speckle_project_ids somewhere else and then querying against those ids.

A hack is to make the project the top-level category for a client, i.e. Levi Strauss (Speckle Project) → [ Alexanderplatz Flagship Store (Speckle Model), Melbourne Store (Speckle Model), Headquarters (Speckle Model) ... Project N (Speckle Model)]. Not great, but then there’s a one-to-one relationship between project (and all children models) and client. There might be other benefits of this structure such that I could query data on all children for a given client, but haven’t looked into it.

In terms of managing a models, I’m interested (maybe rightly or wrongly) in enforcing a rigid model/submodel structure for each project. I know Speckles moved away the github analogy but something like ensuring there’s a main, dev but an AEC equivalent which might be tender, design, manufacturing asbuilt – I think I can enforce this programmatically, but returning to metadata, having attributes on models would be useful for segregating between models within projects (as in the above client-as-project example) or against models across projects, i.e. all tender models with a metadata region attribute of North America, or client attribute of Levi Strauss.

Part of the desire for this structure would be for something like a client portal where we could query for all asbuilt models, if there was metadata on the model we might event be able to query for all client asbuilt models that are for a particular client project manager or client-user, although this relies on Speckle allowing arbitrary project/model metadata (which I think globals allowed for?).

Again I could handle all these relationships elsewhere but it would simplify querying if it was handled within Speckle. Hopefully above context makes sense and is useful!

2 Likes
8

Luke, this is pure gold. I’ll cc @benjavo for visibility on this. Our current plan of attack is:

  • Automate integration into FE2 (for consistency’s sake) - WIP, should be done end of this week
  • Workspaces - basically the equivalent of a github org
  • Management features that you have described above + Day to day value drivers

When it comes to the last bullet point - you basically almost set our roadmap for us a bit. What I’m parsing:

  • project grouping: this will be achievable via a custom project field, ie. client. I think we’ll need some more scoping here, to see how we could assertively already create some of these, allow you to create your own set of custom fields and apply them to all projects, etc.
  • project templates: enforce a model structure from a given set of templates, which can be described at a workspace (org) level.
  • client facing portals: yes (needs more scoping, but you’ve described it quite well). It will have implications on permissions too, but we’re planning to have extra flex there.

This is just the start :slight_smile:

4 Likes
9

Thanks @dimitrie, this all makes sense, and happy to hear it aligns with the roadmap.

I’ll follow-up with two more thoughts:

  1. re Project Templates – something I’m nervous about is visibility control across user groups. Using the client-portal example again, being able to stage-gate, and/or review pushes to a “protected” project/branch would be important for avoiding models being made externally visible on accident (or unnecessarily triggering computationally heavy automated flows maybe?). Using a github example of a release could be helpful way of thinking of it, but really something that makes downstream actions more controllable/deliberate.

Conversely I would consider having models for tender/development/manufacturing/asbuilt as excessive if they’re only to delineate important model states or control what is internally/externally visible. Having a field in metadata (like a release tag) might allow for a structure that enable models to remain linear (keeping diffs intact? potentially reducing stale models or bloat?)

  1. Local commits! Apologies for continuing to use git terminology but being able to commit locally before pushing to main is something I’ve thought we’d have to implement so that the actual speckle server stays somewhat clean, my hunch is it could be implemented via local transports to some kind of local-temporal speckle server? This may be excessive given you can just “save” in most software.

I’m sure this is all things you’ve considered and have likely popped up elsewhere on the forum but that’s my two-cents at the moment.

2 Likes