Unwanted Master GDL in the libraries

[agroni]

Hi everyone,

for some years now, we have been battling some unwanted Master GLD Libraries in our Teamwork projects. I have recently found out, that other offices are facing the same occurrence.

Let me explain what is happening...

We start the project with a clean template, where only our standard libraries are available. During the project development, more or less after 1-2 moths, these libraries located in some strange folders start appearing. 

or here

You will probably think that is it from copying elements from other files. I can guarantee that this is not the case.

We have also tried the option of cleaning all related teamwork files. Nonetheless, the libraries appear after some weeks or months again. Because we don't receive error messages of missing libraries (after deleting them), this means that these libraries are not in use. We started to notice this problem already in Archicad 24. We are getting these master GDLs:

MASTER_GDL_ArchiCAD_Library.gdl

MASTER_GDLVelux81de_DB.gdl

ArchiCAD_Library_Master.gdl

Following my observations, I can conclude that the amount of those libraries might have a slight impact on performance. Still, we want to have super clean teamwork files, therefore it is bothering me a lot.

Does anyone have a similar case?

Why do they appear?

Did you manage to solve it?

I am very thankful for any input...

thanx

[Lucian Laculeanu]

The best solution is to be alone in the file and reserve all when yo do that.

For some weird reason, some of there rogue scripts are replacing attributes sometimes and if you do not replace them with the originals in a controlled manner, you will have missing attributes in your model. If you do that while the affected objects are reserved by others, you have a high chance for the affected attributes in those objects to just go missing.

Deleting libraries IMO has to be done 1by1 anyway because you should verify if any of the contents are used in the project and in what volume so you know what to expect after you delete the library.

[GabrielGG]

I will bring this Post back to live with another frustrated Archicad Manager of a 100+ office that has the complete Practice full of Master-GDLs creating unwanted Attributes like Surfaces, Lines and Layers.

As a solution I would propose that Graphisoft allows to apply the BIMcloud/Permissions to master GDLs separately
I included this Problem in a Post with 2 examples of Archicad Permissions Loopholes:

https://community.graphisoft.com/t5/Teamwork-BIMcloud/BIMcloud-Role-Permissions-Loophole-2-Examples/...

Gabriel

[Lucian Laculeanu]

Best advice:

- do it in the morning with a cool head

- coffee or whatever gives you pleasure

- avoid distractions

- reserve the whole project and ignore messages

- kick everyone from the project and request that they delete their local library copy

Good luck!

[Patrick M]

honestly, its such a toxic and volatile pollutant. Typically it transfers from project to project when copy/pasting from one file to another; but I've personally seen it happen even when nothing has been copy/pasted.
I have opened a file, done absolutely no work whatsoever to the proect, not even reserved anything. Open the attribute manager, and there are 100-200 new surfaces added, simply by the act of joining the file. And I know they are new surfaces because they are underlined, indicating they are in my local data only. Check the embedded library, and sure enough, there is the Master_GDL.gsm files.
The best I can figure, this bug (feature?) has evolved to include cross pollution from local data caches, since this occurred when I had 2 files open.
To Gabriel's comment, I too manage a 100+ person firm, and several medium and smaller size firms. Virtually every one of them has this issue on some level, and constantly struggles to keep their files clean.
At this point, the effort it takes to purge it out of an office is simply not worth it. I am at the point of instructing teams/offices/firms to simply delete the polluted surfaces at the start and end of the day. Not as a clean up measure, just as a way to get the files workable for the day.

[martin-b]

My solution was just keeping the Library Manager and Surfaces reserved at all times on TW projects. That way, when the Master_GDL "virus" created new Library objects or Surfaces for some users, they couldn't send the changes and infect the project. They had to delete all the newly created attributes before they could send changes. 

A bit annoying, but a lot less anoying than cleaning a large TW project with tens of modules. But luckily, the newly created attributes were relatively easy to delete because since I had the attributes reserved, they could just select all in the Atribute Manager and delete all "unreserved" - which was only the newly created stuff.

I was also considering creating new Roles in the BIMcloud where people would not have the possibility to edit Libraries or Attributes...

[GabrielGG]

The possibility of creating the new roles won't help much because the embedded Library is not controlled with the Roles. Everybody has allways access to it ... There are always loopholes in the Attribute management ... you can also have a look at this post BIMcloud Role/Permissions Loophole (2 Examples) 

The Embedded Library should be controlled with the Teamwork Roles as it's the way that Master GDLs get injected in the files while doing Copy-Paste, Hotlinking, etc.

[martin-b]

Interesting, I didn't know about these loopholes. I haven't played that much with the Roles, I just assumed that it would work the same as if I, as the BIM manager, have the Libraries / Attributes reserved.

Then the others "can" create new attributes or Libraries on their local copy, but if they do so, they can't use the Send command and infect the TW project for others.