Problems found while replicating Founding Member sample exercise on a Mac.

[JackConradGray]

The bug report that Claude assembled looks good to me. Nice to have that automated support. I hope it is useful.

I am concerned that Claude may have missed the point, but I can't keep up with all of Claude's insights. The problem might be something I did with my naive level of newbie thinking. Perhaps something due to using MacOS--I already needed to avoid a few Mac related bumps in the road.

Please let me know.

Here is Claude's bug report. it looks like Git generated a URL for it--making things easier to communicate.
clashfind-cde-bug-report.md

-Jack

[HoyosJuan]

Hey Jack! Happy to help.

I see, based on the report, errors are coming from the CDEManager. One question before going any further. Does the builtin CDE app works correctly? Does it display the files and folders you have not been able to see when using the CDEManager in your own app?

Thanks!

[dylan-island]

I noticed something similar. Not sure if same issue. When I scaffolded the 'starter app' following the steps in the tutorial, the assets panel only returned files at the top-level of folder structure. No folders or files inside of folders within the CDE were shown. I had to add my own folder/file nav.

[HoyosJuan]

@dylan-island, in your case if we update the files panel from the scaffold with a tree structure of folders and files, would be enough?

[JackConradGray]

I am able to load files into the CDE and moves them into the file tree. I cannot figure out to remove a file though. And it let me include a folder but it did not unfold the file structure for me which I was expecting. The folder name shows up as a file name. Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/>

…

On Jul 15, 2026, at 11:25 AM, Juan Hoyos ***@***.***> wrote: HoyosJuan left a comment (ThatOpen/platform_services#25) <#25 (comment)> Hey Jack! Happy to help. I see, based on the report, errors are coming from the CDEManager. One question before going any further. Does the builtin CDE app works correctly? Does it display the files and folders you have not been able to see when using the CDEManager in your own app? Thanks! — Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AAU546QED4HUAGTJURZ5YUD5E6PABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGIZTCMRUG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4982312473>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU546STEBGGY7JRLBCFBKD5E6PABAVCNFSNUABFKJSXA33TNF2G64TZHM4DENRYHA3TSNZVHNEXG43VMU5TIOBZGM3TANBUGU2KC5QC>. You are receiving this because you authored the thread.

[HoyosJuan]

Ok @JackConradGray, those are great details. Let me explain a couple of things and get your insights on it:

1. First of all, you can't remove files but archive them. To do it, you need to bulk edit your files. It's easy: just clic in the "edit" button in the toolbar at the top-right of the files panel. Then after, the view will change and let you archive files, change names, and edit properties. Everything is done in one shot, so you can make multiple edits and then commit them all. To archive them, you just enter the edit mode and clic the first icon at the right of the file. Now, one possibility to improve this system is just to allow users to do "quick actions" without entering the full edit mode. That would be, to select multiple files and enable an "Archive" button in the same toolbar, to do it immediately. That would be more user friendly? Or you think knowing about the "Edit" mode is enough?

2. Not sure if I fully understand your "include a folder but it did not unfold the file structure" comment. Perhaps you were expecting to have a single folder + files tree, where you can unfold the folders to see the files inside. Is that right? Because if that's the case, the fact that it's not working like that is actually intended. You see, we have taken inspiration from other systems where you have two trees: one for the whole folder structure, and another one (which is not actually a tree it-self) to list all the files in the selected folder. That way, you always have a quick snapshot over your whole folder structure and then the files inside any you select. Also, this system allows you to create metadata views (metadata trees) based on your files info. So, basically, you create folders in the left panel, access them to make any the active folder, and then work with the files inside of it.

Does these explanations help you somehow?

[dylan-island]

@dylan-island, in your case if we update the files panel from the scaffold with a tree structure of folders and files, would be enough?

Yes, certainly.
The solution I've built in the meantime goes one step further -- the top panel is a small file browser, and below I added another panel that takes inspiration from the "Selection Tree" from Navis, so you can see a list of your currently loaded files, toggle them on/off, etc. Though that is perhaps getting outside the scope of this particular issue.

[JackConradGray]

Juan, Thanks for the quick feedback. My responses iare nline. Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/>

On Jul 15, 2026, at 1:04 PM, Juan Hoyos ***@***.***> wrote: HoyosJuan left a comment (ThatOpen/platform_services#25) <#25 (comment)> Ok @JackConradGray <https://github.com/JackConradGray>, those are great details. Let me explain a couple of things and get your insights on it: First of all, you can't remove files but archive them. To do it, you need to bulk edit your files. It's easy: just clic in the "edit" button in the toolbar at the top-right of the files panel. Then after, the view will change and let you archive files, change names, and edit properties. Everything is done in one shot, so you can make multiple edits and then commit them all. To archive them, you just enter the edit mode and clic the first icon at the right of the file. Now, one possibility to improve this system is just to allow users to do "quick actions" without entering the full edit mode. That would be, to select multiple files and enable an "Archive" button in the same toolbar, to do it immediately. That would be more user friendly? Or you think knowing about the "Edit" mode is enough?

It is mostly clear to me the way it is. I imagined there would be delete though, in case of a mistake, rather than archiving the mistake. The. one mistake I wanted to correct was when I picked an OS folder and expected it to bring in the file tree under that folder—now I have an OS folder in one my CDE folders. I don’t think that is a meaningful state. Am I right? If so can you prevent and warn?

Not sure if I fully understand your "include a folder but it did not unfold the file structure" comment. Perhaps you were expecting to have a single folder + files tree, where you can unfold the folders to see the files inside. Is that right?

Yes

Because if that's the case, the fact that it's not working like that is actually intended. You see, we have taken inspiration from other systems where you have two trees: one for the whole folder structure, and another one (which is not actually a tree it-self) to list all the files in the selected folder. That way, you always have a quick snapshot over your whole folder structure and then the files inside any you select. Also, this system allows you to create metadata views (metadata trees) based on your files info. So, basically, you create folders in the left panel, access them to make any the active folder, and then work with the files inside of it. Does these explanations help you somehow?

It is a reasonable design, but I feel that not allowing the user to select an OS folder to add to the CDE would clarify the intent. Unless there is a meaningful use of a OS folder name in the CDE that I have not thought of.

…

— Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AAU546V7GH6W3CZJDTN56ED5E62THA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGMZDONBRGAY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4983274101>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU546QTZ4TO2IRUPXCFAAD5E62THAVCNFSNUABFKJSXA33TNF2G64TZHM4DENRYHA3TSNZVHNEXG43VMU5TIOBZGM3TANBUGU2KC5QC>. You are receiving this because you were mentioned.

[JackConradGray]

Dylan, My bug report noted something similar. But, I was able to build a query off our a .frag that did not show up in the "Assets > Project Files” panel (for clarity note that there is also an "Assets > Objects” panel, both opened by the [Assets] button)p One .frag file from my WIP>Architecture folder did show up when I was setting up a query. Oddly the Duplex….ifc file in my WIP>Plumbing folder did not create a .frag file even though the UI signaled that it was started and processing. All of that vanished when I looked again and there was no indication of error visible in the UI. Having the.frag files is on the critical path, no? Maybe a workaround hack would be to delete the .ifc then try again, but it should just work or report why it failed, no? (Reporting the problematic step in the .ifc would be useful no matter whose bug it is). Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/>

…

On Jul 15, 2026, at 11:56 AM, Dylan Bush ***@***.***> wrote: dylan-island left a comment (ThatOpen/platform_services#25) <#25 (comment)> I noticed something similar. Not sure if same issue. When I scaffolded the 'starter app' following the steps in the tutorial, the assets panel only returned files at the top-level of folder structure. No folders or files inside of folders within the CDE were shown. I had to add my own folder/file nav. — Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AAU546UHPLDX5G2FRARFTBL5E6STFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGI3DEMZVHA42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4982623589>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU546UI5OOJLXHH3HIPU4L5E6STFAVCNFSNUABFKJSXA33TNF2G64TZHM4DENRYHA3TSNZVHNEXG43VMU5TIOBZGM3TANBUGU2KC5QC>. You are receiving this because you authored the thread.

[JackConradGray]

Dylan, I would love to see sample code for your modification creating the "CDE Browser” panel. I need to dig deeper and wrap my head around all aspects of the existing code. Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/>

…

On Jul 15, 2026, at 4:14 PM, Jack Gray ***@***.***> wrote: Dylan, My bug report noted something similar. But, I was able to build a query off our a .frag that did not show up in the "Assets > Project Files” panel (for clarity note that there is also an "Assets > Objects” panel, both opened by the [Assets] button)p One .frag file from my WIP>Architecture folder did show up when I was setting up a query. Oddly the Duplex….ifc file in my WIP>Plumbing folder did not create a .frag file even though the UI signaled that it was started and processing. All of that vanished when I looked again and there was no indication of error visible in the UI. Having the.frag files is on the critical path, no? Maybe a workaround hack would be to delete the .ifc then try again, but it should just work or report why it failed, no? (Reporting the problematic step in the .ifc would be useful no matter whose bug it is). Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/> > On Jul 15, 2026, at 11:56 AM, Dylan Bush ***@***.***> wrote: > > > dylan-island > left a comment > (ThatOpen/platform_services#25) > <#25 (comment)> > I noticed something similar. Not sure if same issue. When I scaffolded the 'starter app' following the steps in the tutorial, the assets panel only returned files at the top-level of folder structure. No folders or files inside of folders within the CDE were shown. I had to add my own folder/file nav. > > — > Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AAU546UHPLDX5G2FRARFTBL5E6STFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGI3DEMZVHA42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4982623589>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU546UI5OOJLXHH3HIPU4L5E6STFAVCNFSNUABFKJSXA33TNF2G64TZHM4DENRYHA3TSNZVHNEXG43VMU5TIOBZGM3TANBUGU2KC5QC>. > You are receiving this because you authored the thread. >

[JackConradGray]

One workflow that occurs to me is that if you could bring an OS file tree Ito the CDE all at one, you could then drag and drop more than one file from it into the CDE file tree then delete the rest (if there were a delete. There is an archive, but is there a reciprocal way to unarchive a file if one makes a mistake? Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/>

…

On Jul 15, 2026, at 3:53 PM, Jack Gray ***@***.***> wrote: Juan, Thanks for the quick feedback. My responses iare nline. Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/> > On Jul 15, 2026, at 1:04 PM, Juan Hoyos ***@***.***> wrote: > > > HoyosJuan > left a comment > (ThatOpen/platform_services#25) > <#25 (comment)> > Ok @JackConradGray <https://github.com/JackConradGray>, those are great details. Let me explain a couple of things and get your insights on it: > > First of all, you can't remove files but archive them. To do it, you need to bulk edit your files. It's easy: just clic in the "edit" button in the toolbar at the top-right of the files panel. Then after, the view will change and let you archive files, change names, and edit properties. Everything is done in one shot, so you can make multiple edits and then commit them all. To archive them, you just enter the edit mode and clic the first icon at the right of the file. Now, one possibility to improve this system is just to allow users to do "quick actions" without entering the full edit mode. That would be, to select multiple files and enable an "Archive" button in the same toolbar, to do it immediately. That would be more user friendly? Or you think knowing about the "Edit" mode is enough? > It is mostly clear to me the way it is. I imagined there would be delete though, in case of a mistake, rather than archiving the mistake. The. one mistake I wanted to correct was when I picked an OS folder and expected it to bring in the file tree under that folder—now I have an OS folder in one my CDE folders. I don’t think that is a meaningful state. Am I right? If so can you prevent and warn? > Not sure if I fully understand your "include a folder but it did not unfold the file structure" comment. Perhaps you were expecting to have a single folder + files tree, where you can unfold the folders to see the files inside. Is that right? > Yes > Because if that's the case, the fact that it's not working like that is actually intended. You see, we have taken inspiration from other systems where you have two trees: one for the whole folder structure, and another one (which is not actually a tree it-self) to list all the files in the selected folder. That way, you always have a quick snapshot over your whole folder structure and then the files inside any you select. Also, this system allows you to create metadata views (metadata trees) based on your files info. So, basically, you create folders in the left panel, access them to make any the active folder, and then work with the files inside of it. > > Does these explanations help you somehow? > It is a reasonable design, but I feel that not allowing the user to select an OS folder to add to the CDE would clarify the intent. Unless there is a meaningful use of a OS folder name in the CDE that I have not thought of. > — > Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AAU546V7GH6W3CZJDTN56ED5E62THA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGMZDONBRGAY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4983274101>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU546QTZ4TO2IRUPXCFAAD5E62THAVCNFSNUABFKJSXA33TNF2G64TZHM4DENRYHA3TSNZVHNEXG43VMU5TIOBZGM3TANBUGU2KC5QC>. > You are receiving this because you were mentioned. >

[JackConradGray]

Trying some workarounds I went back to my project CDE and archived the file that was actually a folder—that worked fine. I then archived the "Duplex_P….ifc" file in my WIP>Plumbing folder and re-uploaded it from the OS file system. I did not leave the page and it built the .frag quickly. I left the .ifc and .frag in the top project folder. I went back to my local app and the "Duplex_P….frag" file shows up in Project Files. Then in the CDE I moved the two new "Duplex_P….” files to my WIP>Plumbing folder. Now the .frag file no longer shows up in the app Project Files. I looked at my WIP>Architecture folder and saw that my ifc and frag files there are both duplicated! Each duplicate is noted as v1. I have no idea how to reproduce that. But I saw it. I archived a duplicate .ifs and .frag, then went back to the local app. Neither of those show up in the app Project Files. Now I make a fresh start. The problems have become clearer. I have archived all the files in the CDE. I believe what follows is all reproducible. In the CDE project’s top-level folder, I upload the “Duplex_A….ifc” and “Duplex_P….ifc” files. These files then generate the .frag files. Subsequently, I open the local app and observe that all the .ifc and .frag files are displayed in the Project Files pane. Upon returning to the CDE application, I drag/drop the corresponding files into the Architecture and Plumbing subfolders. However, upon reopening the local application, the Project Files pane is now empty. What is the reason for this discrepancy? In the CDE, I now upload “Duplex_E….ifc” directly into my Electrical subfolder and wait for the .frag file to complete. Upon examining the Architecture and Plumbing subfolders, I observe that the corresponding .ifc and .frag files are duplicated, each marked as version 1. Then by selecting one of each duplicate file and executing the “Edit” command, then the archive command, both duplicates are removed. That makes some sense since there is really only one underlying file for each duplicated file name. Having deleted all my other files from the CDE, I now have only the .ifc and .frag in my Electrical subfolder. Back in the local app, I see nothing in the Project Files pane. I drag/drop the “Duplex_E….ifc” and “Duplex_E….frag” into the top-level CDE folder. In the app, I now see both in the Project Files pane. If I click the show icon on a .ifc file in the app, then the code regenerates the corresponding .frag, shows a duplicated .frag name for a second, then removes one of the duplicate .frag names, before rendering the .frag in the 3D scene. Here is what I think should happen instead: 1) If I upload a .ifc file into a CDE subfolder, it should become visible in the app Project Files pane regardless of where the .ifc file is in the CDE file tree. 2) If I upload a .ifc file into a CDE subfolder, it should generate the corresponding .frag into the same CDE subfolder no matter where I navigate to in the UI. If there is a .frag conversion error, it should put an indication of that in the same CDE subfolder and provide a retry if it would be useful. 3) If I drag/drop a file between CDE folders ir should still show up in the app Project Files pane. 4) If I drag/drop a file from one CDE folder to another, it should never show duplicate file names. 5) If I click the show icon on a .ifc file in the app and there is no .frag, it should generate a .frag and show it, but it should never generate a .frag if it already has one—it should simply show the .frag in the 3D pane. Maybe once there is a .frag its .ifc file should be ghosted? Are there better alternatives to any of these that I am not seeing? All of these can be worked around carefully to make the system usable but until you learn those workarounds it is confusing and a time sink—misplaced cognitive load. As much as possible preventing confusion in new users makes product use easier and more fun. No? Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/>

…

On Jul 15, 2026, at 4:14 PM, Jack Gray ***@***.***> wrote: Dylan, My bug report noted something similar. But, I was able to build a query off our a .frag that did not show up in the "Assets > Project Files” panel (for clarity note that there is also an "Assets > Objects” panel, both opened by the [Assets] button)p One .frag file from my WIP>Architecture folder did show up when I was setting up a query. Oddly the Duplex….ifc file in my WIP>Plumbing folder did not create a .frag file even though the UI signaled that it was started and processing. All of that vanished when I looked again and there was no indication of error visible in the UI. Having the.frag files is on the critical path, no? Maybe a workaround hack would be to delete the .ifc then try again, but it should just work or report why it failed, no? (Reporting the problematic step in the .ifc would be useful no matter whose bug it is). Jack Gray ***@***.*** 617.513.8185 LinkedIn <https://www.linkedin.com/in/jackgray/> > On Jul 15, 2026, at 11:56 AM, Dylan Bush ***@***.***> wrote: > > > dylan-island > left a comment > (ThatOpen/platform_services#25) > <#25 (comment)> > I noticed something similar. Not sure if same issue. When I scaffolded the 'starter app' following the steps in the tutorial, the assets panel only returned files at the top-level of folder structure. No folders or files inside of folders within the CDE were shown. I had to add my own folder/file nav. > > — > Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AAU546UHPLDX5G2FRARFTBL5E6STFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGI3DEMZVHA42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4982623589>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU546UI5OOJLXHH3HIPU4L5E6STFAVCNFSNUABFKJSXA33TNF2G64TZHM4DENRYHA3TSNZVHNEXG43VMU5TIOBZGM3TANBUGU2KC5QC>. > You are receiving this because you authored the thread. >

[JackConradGray]

I loaded four IFC files from the GitHub "Community-Sample-Test-Files/IFC 2.3.0.1 (IFC 2x3)/Duplex Apartment" folder: the architectural, electrical, MEP, and Plumbing to test out the clash detection build that I created. Each IFC triggered a FRAG to be generated.

Note the multiple presentations of the architectural and MEP, but not of the plumbing and electrical. These just showed up as I was loading the IFCs and the FRAG's were finishing. Note also the inconsistency in the FRAG's authors.

In the running app there are also some duplicate FRAG files listed in the Project Files panel. I am able to show any of the four files. The inconsistency of the UI is distracting. At one point I got a bunch of server access failures and could not toggle the visibility of any of the four files. I restarted the app and the problem went away, though the duplicate FRAG names persisted.

If I use this test case or similar test case for building my own app, am I responsible for cleaning up UI the things that annoy me or is there a platform team that is working toward a well behaved UI state for these sample apps?

[HoyosJuan]

Hey Jack and Dylan, thanks so much for all the detail here! Let me go through everything:

1. Project Files panel only showing top-level files
This is now fixed! The panel has been updated to a table showing the full file structure. Note this table is scoped to files that can actually be visualized in the 3D world, since it's specific to the viewer app, not a general file manager (that's what the CDE is for).

2. Duplicate .frag files / missing .frag after moving / no error on failed conversion
These three likely share the same root cause. The link between an IFC and its corresponding .frag file gets broken when the file is moved, so the system treats it as if the .frag doesn't exist, leading to the duplication and inconsistency you saw. This is next on our list to fix!

3. Inconsistent .frag authors
The conversion is done by an internal cloud component of the platform, which gets registered as the "author" instead of a person. We'll look into improving this.

4. Dragging an OS folder into the CDE
Great catch! We agree this is worth implementing properly. The expected behavior will be: the OS folder gets created as a CDE folder, and its files get added as files inside that new folder, recursively, so nested folders behave the same way.

5. Un-archiving files
This is already possible from the CDE! Just click the button in the header of the Groups panel (left panel) in the CDE. It toggles the view to show archived folders/files so you can restore them. Note the Project Files panel doesn't support archive/unarchive, since its purpose is visualization, not file management, that's exactly why the CDE exists as a separate, full featured tool.

6. Is the user responsible for cleaning up UI inconsistencies in the sample apps?
Absolutely not! You're only responsible for cleaning up inconsistencies in your own custom UI. Built-in platform components are on us at ThatOpen to get right, as we just did with the Project Files panel, which now shows the full visualizable file tree regardless of folder location.

Thanks again for the thorough testing!

[JackConradGray]

Excellent!Many thanks Dylan for this mini roadmap and for sharing TOC operating principles.This will allow my mind to focus on creating my first app.  I am excited to see how long it will take.Jack ***@***.*** Jul 17, 2026, at 8:09 PM, Juan Hoyos ***@***.***> wrote:HoyosJuan left a comment (ThatOpen/platform_services#25) Hey Jack, Dylan, thanks so much for all the detail here! Let me go through everything: 1. Project Files panel only showing top-level files This is now fixed! The panel has been updated to a table showing the full file structure. Note this table is scoped to files that can actually be visualized in the 3D world, since it's specific to the viewer app, not a general file manager (that's what the CDE is for). 2. Duplicate .frag files / missing .frag after moving / no error on failed conversion These three likely share the same root cause. The link between an IFC and its corresponding .frag file gets broken when the file is moved, so the system treats it as if the .frag doesn't exist, leading to the duplication and inconsistency you saw. This is next on our list to fix! 3. Inconsistent .frag authors The conversion is done by an internal cloud component of the platform, which gets registered as the "author" instead of a person. We'll look into improving this. 4. Dragging an OS folder into the CDE Great catch! We agree this is worth implementing properly. The expected behavior will be: the OS folder gets created as a CDE folder, and its files get added as files inside that new folder, recursively, so nested folders behave the same way. 5. Un-archiving files This is already possible from the CDE! Just click the button in the header of the Groups panel (left panel) in the CDE. It toggles the view to show archived folders/files so you can restore them. Note the Project Files panel doesn't support archive/unarchive, since its purpose is visualization, not file management, that's exactly why the CDE exists as a separate, full featured tool. 6. Is the user responsible for cleaning up UI inconsistencies in the sample apps? Absolutely not! You're only responsible for cleaning up inconsistencies in your own custom UI. Built-in platform components are on us at ThatOpen to get right, as we just did with the Project Files panel, which now shows the full visualizable file tree regardless of folder location. Thanks again for the thorough testing! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[HoyosJuan]

Hey @JackConradGray, here we have some updates:

The IFC to FRAG conversion is handled by IfcFragmenter, a cloud component of the platform. When it converts an IFC, it stamps the generated FRAG's id right into the IFC's own metadata. The bug was that the CDE was looking for the paired FRAG by matching file names instead of reading that metadata link. That's now fixed on our end: the CDE reads the real link straight from the IFC's metadata, so moving, renaming, or reorganizing files no longer breaks the pairing.

While working on this we also built the idea you suggested about hiding files once they're linked. Once an IFC has its FRAG, the FRAG is the one that gets hidden, not the IFC, so uploading an IFC never makes your original file seem to disappear. If a FRAG has no paired IFC, it still shows up on its own, for example files coming from other tools that upload a FRAG directly.

This fix isn't merged yet. While digging into it we found a couple more things worth fixing directly in IfcFragmenter itself, around how it stamps metadata across file versions, and we want to close those out first so it all lands together in one clean pass instead of in pieces.

Will keep this thread updated!