View Issue Details

IDProjectCategoryView StatusLast Update
0000740FreeCADBugpublic2012-06-09 13:31
Reporterjmaustpc Assigned To 
Status closedResolutionfixed 
Fixed in Version0.13 
Summary0000740: work bench initiation from in fcstd file
DescriptionFor projects that utilise Draft, Arch, and presumably all Python work benches the fcstd file requires the appropriate Python work bench be initiated before the file is opened, otherwise it doesn't display the Python items in the tree properly.
Steps To Reproducecreate anything in Draft and/or Arch Work Benches, save the file close FreeCAD. Start FreeCAD again then just open the file again immediately without opening the appropriate workbench.
Additional InformationI know there is a security issue with allowing Python code to be stored and run from the fcstd file, as Juergen and others have previously discussed. But I wonder if this below makes sense.

1) list in the fcstd file a list of "work bench dependencies" for that specific fcstd file.
2) have FreeCAD on "open file" first read this list of dependencies and initialise the appropriate work benches? Definitely not any arbitrary code, just only allow initiation of workbenches that the FreeCAD program already knows it contains?

If implemented correctly I don't think it would be a security risk, because all the file is saying is open that pre-existing workbench. Any "bad" code would have to already be in that workbench as part of the FreeCAD application code because all that is transferred from the fcstd file is a text name of a workbench, not any code.

I don't know enough to make a serious detailed proposal but doesn't this make sense? If the "work bench dependency" is just a list of text in the fcstd file then the FreeCAD application would contain all the code to do anything with that data, so it would not matter what the text said, if it did not match a known FreeCAD workbench name then FreeCAD would not execute anything. Presumably the compiled FreeCAD application would contain a list of work bench names in text to compare with those found in the fcstd file, if FreeCAD application finds a match, then it would follow instructions already pre-coded into the FreeCAD application code to initiate the appropriate work benches.
TagsNo tags attached.
FreeCAD Information


2012-06-07 07:47


python_wb_required_before_file_open.jpg (Attachment missing)


2012-06-07 08:46

developer   ~0002141

But this information is/should be allready in the FcStd file. The (c)Pickle Module saves it for every FeaturePython Proxy.
Maybe I'm confusing Module and Workbench.


2012-06-07 10:01

administrator   ~0002142

To load a object its only needed to load the module, the WB need not to be
activated. If python objects are not loaded without the module pre-loaded
its cleary a bug.


2012-06-07 12:13

administrator   ~0002143

As far as I can tell there is no problem... This works without problem:

1) make sure the default WB is not Draft
2) switch to Draft, draw something
3) save the file
4) close and reopen FreeCAD, default WB is StartWB
5) open the saved file

Probably it's your file that has some problem... Looking at your screenshot, looks like the Arch module didn't init correctly, probably because of the bug we talked about in the forum today..


2012-06-09 07:40

administrator   ~0002163

The (c)Pickle module assures that the python module is loaded where the python class is part of. So, when checking a project with an Arch wall you can clearly see in the debugger that the object is properly instantiated.

But the problem that the wrong icon is shown has nothing to do with (c)Pickle. The problem is quite simple: _ViewProviderWall returns a path to a Qt resource file ":/icons/Arch_Wall_Tree.svg" This file, however, is not known as long as the Arch resource file is not loaded. And this resource file gets loaded together with the loading of the Arch module.


2012-06-09 07:51

administrator   ~0002164

git show 0bf33b6
The bug was fixed by explicitly doing an "import Arch_rc" in the getIcon() method of the python view provider classes.


2012-06-09 13:31

administrator   ~0002167

ah indeed, thanks for the fix Werner! Later on I should simplify that by making all Arch objects derived from a same base class...

Issue History

Date Modified Username Field Change
2012-06-07 07:47 jmaustpc New Issue
2012-06-07 07:47 jmaustpc File Added: python_wb_required_before_file_open.jpg
2012-06-07 08:46 shoogen Note Added: 0002141
2012-06-07 10:01 Jriegel Note Added: 0002142
2012-06-07 12:13 yorik Note Added: 0002143
2012-06-09 07:40 wmayer Note Added: 0002163
2012-06-09 07:51 wmayer Note Added: 0002164
2012-06-09 07:51 wmayer Status new => closed
2012-06-09 07:51 wmayer Resolution open => fixed
2012-06-09 07:51 wmayer Fixed in Version => 0.13
2012-06-09 13:31 yorik Note Added: 0002167