TW2 broken Autotext

[SeaGeoff]

I like to place the the name and path, along with the printing date, in small text along the binding edge of my layouts. I just noticed that the File Name and File Path autotexts do not work with shared projects. I get the name/path of the last saved solo project. Somebody missed, or ignored that these no longer work with TW2.

[Rob]

Geoff,

There is no TW2 project file as such so those autotext values are completely irrelevant under TW2... or are you suggesting that they should be turned to nil? or point to the local cache or BIM server project directory? but data there are not usable from OS itself.

I am just not sure what would you like to have there....

[Karl Ottenstein]

What you've found has to be considered a bug, Geoff. Reported?

The file name should be the name of the shared project IMHO - generally that inherits the name of the original project before sharing.

The path IMHO should list the BIM Server name/IP.

Good catch.

Karl

[Edit] PS After posting, it occured to me that there is a lot of other information for which we should have autotext fields for a TW2 project. For example, I'd like to be able to list (if not schedule) all people who are authorized to access the project, whether they made any modifications, when their last 'send' was, etc. ... hmmm... a schedule would be better for that.

[Rob]

[Edit] PS After posting, it occured to me that there is a lot of other information for which we should have autotext fields for a TW2 project. For example, I'd like to be able to list (if not schedule) all people who are authorized to access the project, whether they made any modifications, when their last 'send' was, etc. ... hmmm... a schedule would be better for that.

I disagree. This should be accessible from BIM Server Control Center only. You do not want to necessarily reveal this information to anyone who is accessing TW2 file e.g. from a view-only account. Same with the server path and IP. It could lead to possible exploits on the Internet.

[Karl Ottenstein]

Rob wrote:

Karl wrote:
PS After posting, it occured to me that there is a lot of other information for which we should have autotext fields for a TW2 project. For example, I'd like to be able to list (if not schedule) all people who are authorized to access the project, whether they made any modifications, when their last 'send' was, etc. ... hmmm... a schedule would be better for that.

I disagree. This should be accessible from BIM Server Control Center only. You do not want to necessarily reveal this information to anyone who is accessing TW2 file e.g. from a view-only account. Same with the server path and IP. It could lead to possible exploits on the Internet.

I disagree even more.

The information is visible to every user who is signed into the project, so there is no harm in having it available to them for internal use. If someone is stupid enough to print a page with the IP address, login id and password, that is their problem. ArchiCAD does not prevent anyone from publishing their bank accounts, so there is no reason to constrain information - it is the user's information for them to manage as they see fit.

Sure, some things like team members might only be visible to a lead architect role, but that kind of information is useful to put on internal documents and it belongs as part of the project IMHO. The BIM Server Manager has no report-writing capabilities. The schedule function in ArchiCAD does. It is a no-brainer I think. 😉

Cheers,
Karl

[SeaGeoff]

Geoff wrote:
I like to place the the name and path, along with the printing date, in small text along the binding edge of my layouts. I just noticed that the File Name and File Path autotexts do not work with shared projects. I get the name/path of the last saved solo project.

Quoting myself here. I want (yes I really do) to have the file name (or project name in BIM sever parlance), and the printing date (as opposed to the issue date) on my printouts. It's mostly for internal use but I can see it being helpful to resolve version mistakes in the field. I'm not worried about the potential security issues and besides I have the capability to turn it off. If those are big concerns then just don't do it.

As far as hiding information form certain BIM Server user roles, that is a worthy subject that belongs in another thread.

[Rob]

Sure, some things like team members might only be visible to a lead architect role, but that kind of information is useful to put on internal documents and it belongs as part of the project IMHO. The BIM Server Manager has no report-writing capabilities. The schedule function in ArchiCAD does. It is a no-brainer I think.

Actually it is already there and exportable:
go to - Teamwork/Project/Teamwork Project Settings -->Project Log

[SeaGeoff]

I apologize, I spoke too soon. The autotexts I mentioned do work with TW2, or at least they fixed themselves at some (as yet undetermined) point. Maybe I hadn't done a S/R yet, or maybe you need to quit AC and come back. Either way it works now. The file path autotext gives the path with the sintax:

teamwork://IP Address/File Name

[Anonymous]

Karl wrote:

The information is visible to every user who is signed into the project, so there is no harm in having it available to them for internal use. If someone is stupid enough to print a page with the IP address, login id and password, that is their problem. ArchiCAD does not prevent anyone from publishing their bank accounts, so there is no reason to constrain information - it is the user's information for them to manage as they see fit.

Sure, some things like team members might only be visible to a lead architect role, but that kind of information is useful to put on internal documents and it belongs as part of the project IMHO. The BIM Server Manager has no report-writing capabilities. The schedule function in ArchiCAD does. It is a no-brainer I think. 😉

Cheers,
Karl

A solution to satisfy both viewpoints might be to have that user configurable. There are cases where we might like the system to prevent us from pasting in our bank account instead of something less "sensitive." Likewise there may be some types of easily made mistakes that we would like the system to help prevent (but not with the intrusiveness and uniformity of Vista). In some apps, such as Goldmine, there are configs for beginners, intermediate level users, and masters. Maybe something like that could work.
Among gov't folks, suppressing some fields so that some users are not aware of the fields' existence, may be required. Striking a balance between flexibility and rapid configuration is the art required to make it sensible, easy, and fast for users who have an open environment, yet flexible for those needing a relatively secure environment where a config guru is SOP.