[Problem] Document information isn’t very useful

[pierreporte]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

The document information window looks like this:

For mechanical CAD, there are very common attributes missing like part number while some are not necessarily useful like UUID or license. For Architecture/BIM, I don’t know if it’s good enough. Yet, in any case, the user is stuck with this limited choice. Also, the attributes can’t be used in expressions.

I propose to implement a flexible attribute system where it is possible to define the different attributes to be stored in the file. Depending on the project (standard part, assembly, architecture, …), the attributes could be different. This way, FreeCAD could follow company policies for attributes and work nicely with PDM and PLM systems.

The default attributes could depend on the file type when using the start workbench. Unfortunately, there is no way to have template files yet to fully leverage this.

Here is a proposition:

It is quite similar to the Solidworks equivalent:

The attributes types could be: text, number, list choice (radio or dropdown), date, boolean.

Full version info

0.22

Subproject(s) affected?

Core

Anything else?

Somewhat related to #12120.

Code of Conduct

• I agree to follow this project's Code of Conduct

[pierreporte]

I think that this more or less implies that a file must have only one physical root (either part or assembly). Things like simulations doesn’t count. This topic is discussed in #11742.

[PaddleStroke]

This is related to the current work on document property @pieterhijma @sliptonic may have some ideas on it

[pieterhijma]

@pierreporte, thanks for pointing this out. Reading the issue I notice three issues:

• The document information is static, only some of the properties of the document root in Base are shown, but it is not possible to add your own properties.
• Lack of GUI support for adding these kinds of properties.
• Unable to use these properties in expressions.

It is possible to add your own properties to the document root (right click in the property window -> show all -> add property). It should not be too hard to implement that any property of a group different than Base is added to the document info.

In that case, there is GUI support to add your own properties, but not very good GUI support. This may improve by the work in #12135.

Regarding using document root properties in expressions, PR #10653 addresses this, but it is currently not worked on. It aligns a bit with my tasks, but currently I'm not addressing it, precisely because of #11742.

[pierreporte]

@pieterhijma Thank you for clarifying underlying issues.

If you need the file structure to be settled first, don’t hesitate to take part to the discussion. It has been stalled for more than a months, which is sad considering that it’s a major thing.

[yorikvanhavre]

I would love to see that info screen extended too. @pierreporte your mockups above however will only satisfy part of FreeCAD users. For ex, architects will want completely different info. The one we have at the moment is indeed mostly basic, generic stuff. The way I see this:

• This depends in a large part on having document properties fully working ( @pieterhijma is working on it).
• Different user types have different ideas on what properties constitute "proper document properties"
• Having a second (or third...) tab on that document info screen seems like a good idea. That could be dynamically filled
• This still advocates to not hide the document object in the tree. This is ultimately the best way to make sure what properties a document has

In any case, IMHO I don't think just reworking that document info screen is interesting at this point. We need a better idea of what we should achieve, do we want different kinds of users to see different info, etc...

[pierreporte]

@yorikvanhavre The mockup is indeed oriented towards mechanical engineers because it is what I know. When the issue was created, I asked someone on Discord to give me some input for what attributes are important for architecture. Don’t hesitate to make proposals for this.

This still advocates to not hide the document object in the tree. This is ultimately the best way to make sure what properties a document has

From a mechanical engineering point of view, Part and Assembly containers are enough to hold the attributes. The problem is for other kind of work like BIM. This subject is thus linked to the file structure discussion #11742. Maybe we could have a Building container? Edit: there is already a building, site and, even project container. If all files need a root (not only can), which hold all information, then the document object can be dropped in single document mode. This could lead to compatibility issues (this question is the discussion).

In any case, IMHO I don't think just reworking that document info screen is interesting at this point. We need a better idea of what we should achieve, do we want different kinds of users to see different info, etc...

Yes, the dialog is a symptom. It’s not bad per se. When its content is decided, it will naturally come into shape.

[marcuspollio]

Hi everyone !

Here are some comments form an architecture and construction perspective, after my tiny experience mostly in small and medium-sized companies in central Europe. Input about workflows from other backgrounds by other people are greatly appreciated, also among other disciplines (civil engineering, HVAC and electrical, landscape, urban planning, etc.).

This does not only concern this Document Information dialog but also properties/attributes management in general for this domain (construction).

First let's acknowledge that, despite some standards, norms and conventions (international, national or regional) and even guidelines (internal to companies), information management practices are very loosely observed (even among older businesses), for a number of reasons (deadlines, personal habits, lack of interest, staff turnover, etc.) It's often quite chaotic. Fortunately, there are exceptions. =D
Therefore, the design of a flexible and coherent system in FreeCAD does not necessarily have to be dictated by the current practices, but can afford to be innovative and forward-thinking (what our industry is hardly).

There are two main practical aspects to consider: file management (A) and informations retrieval (B).

Most companies do not have advanced file management solutions. This is usually done locally (computers or server), using a classic folder structure and more or less explicit file names.
While some companies have adopted databases or make extensive use of templates for some daily tasks (administration, accounting, etc.), anything related to design, modelling, drawings, simulations, etc. is by no means there yet.
The management of versions, revisions, phases and levels of details over the course of projects, which last easily between three to ten years and more, is often inconsistent and messy within a single company. Imagine when there are a dozen other partners (engineers, external specialists) and around thirty construction firms (masons to curtains fitters to everything in between).
No single universal system will solve this maze.

We can nevertheless consider some ways of helping people organise more easily : use pre-defined or customised properties to meet various scenarios. FreeCAD is very good for this flexibility (expressions, aliases), not so good for making it easily accessible, not too cumbersome, integrated and coherent across the whole software. =P

(A) The file management possibilities we can imagine are: generate file names and metadata (when saving FCStd and every exportable file) according to a schema of properties using stored values, or integrate properties based e.g. on the IFC schema for construction scenarios (WIP by Yorik for native-ifc authoring) that can be easily used by distributed version control systems (see the Git revisions tracking in BlenderBIM).

(B) This also apply to what is produced and generated within the workbenches (models, drawings, simulations, etc). We often deal with heaps of objects/groups/parts/whatever (>10'000 is common), so any improvement is welcome. Each input field should be able to call properties if need be, as you can now for most object datas (labels, dimensions, placement, features, tags, etc.) The TechDraw workbench has recently taken a first step in this direction, but it is a bit of a makeshift operation and not properly integrated as expressions. While Draft objects can be modified by expressions in the data/properties panel, this is not the case for its task panels nor its modification tools (ok, it's a drafting workbench, but still). The worst are Draft_Text, Draft_Label, Arch_AxisTools, etc. that use this annoying popup window. But let's not mix things up, it's for a different issue.

There are three potential points of action:

(1) The FreeCAD user configuration at the application level. See the user profiles in other softwares or what Abdullah proposed. It can affect the working environment (user preferences), and some resulting values can be retrieved internally by the user if need be. Some custom properties can also be set and shared among users thanks to profiles. Think here of the kind of information/properties within the company, to a working group, linked to the user, or that can be similar for several projects. Should these properties be transfered to the document, I don't know yet. It's maybe not the most urgent topic to implement, but may be convenient on the longer term for bigger usecases.

(2) Properties at document level, which is what we're mostly talking about here. At this point, it can become very broad: project name, project code or ID, site address, contact details, geographic coordinates and altitude, various stakeholders (client, principal contractor, etc.) and theirs specific details, various dates, classification scheme, revision scheme, versions, phases, units, author, quality control, special notes such as "all measures to be checked on site and notify construction managers when necessary", etc. Depending on whether a main file with everything or an assembly of different linked files is used, the properties at document level will vary. Some of this informations can be inserted in TechDraw templates if it's only used there. Should all the imaginable properties implemented ? I don't think so. Should a curated list be established by the community, maybe ?

(3) The system we now know at the level of objects/parts/groups/assembly, etc. It's more a question of improving the user experience.

At the end of the day, it's often about context: how to make the best use of the different properties already there in the present situations, easily linking and setting a structure efficient and robust, because change is permanent in projects (if it's too intertwined, it will probably break at some point). So we focus more on the project, on design, on better outputs and less on a miriad of tiny updates that can be automated and cause errors, which has real-world consequences. And also collaboration: facilitating coordination, accessibility and clarity of information leads to better feedback, responsiveness and less hair pulling for everyone =D

Thank you !

[pierreporte]

Thank you @marcuspollio for your detailed comment.

The main point of your text is that the attributes system must be very flexible to allow for all kinds of working environments, companies, standards, and personal preference. This is perfectly in line with fully customizable attributes. In mechanical engineering, it is less flexible but every company works a little bit differently so there is definitely no one-size-fits-all.

I think that the best way to handle different file type is to have templates, that are normal FreeCAD files but stored in a folder (local or shared). They would all have their own set of attributes and some containers (for a part, it would be a Std_Part with a Std_Body in it). Users and companies can easily make new ones to suit their needs.