Changing the Revision Date in AC 18

[Anonymous]

I must be missing something using the Revision Manager in AC 18...

When an issue is currently open, the issue date is automatically set to "work in progress". We cannot set the date manually.

When an issue is closed, the issue date is automatically set to the date the "close issue" button was clicked. We cannot set the date manually.

Anyone know how to manually set the date?


thanks

[__archiben]

Gergely wrote:
- New items not inheriting the naming scheme: This might be a bug; it is expected to behave the same way as with file types: If all are the same in one folder, the new one inherits that, if they are different, it inherits a default. I will check and log it.

If you could look at this I would really appreciate it - it's been bugging me for as long as the navigator has been around and I honestly thought that it was by design rather than a bug...! just to be sure we're talking the same language:

if i set a series of parameters on the top parent of the navigator tree, all new items that get added to the tree will inherit those settings rather than some system default or default settings that exist in the viewpoint at the time? by extension, if i set a series of parameters on a folder in the view map or publisher, any item that gets added automatically to that folder inherits the settings of the folder rather than the default setting of the navigator tree?

please tell me it's a bug that you're going to nail in the next hotfix and i will be very happy!

~/b

[__archiben]

laszlonagy wrote:
This clip may be helpful about the Publisher Set renaming as it shows that you can type normal text as part of the code for those custom names:

https://www.youtube.com/watch?v=2bKxs-PIpH4

my issue is with the automation of things lazslo - publishing automation in particular has the potential to save hours and hours of mundane work yet is only partly working so in fact the time saved in what does work well is spent checking things to make sure all of the published items did in fact get created as intended. i exaggerate: it does save time of course but it could save much more!

when joe user opens a new project from a template file and duly fills in the known Project Information, shouldn't that get propagated to the areas where it's needed throughout the file? if the job number is already there let's use it wisely!

i've already in fact used normal text in my naming for something that is constant across every single project it's in: the word " Rev "

<CURRENTISSUECUSTOMPAR1>_<SourceID> Rev <CURRENTREVISIONID>-<SourceItemName>

at the moment i'm using '<CURRENTISSUECUSTOMPAR1>' as the project number which requires it being typed in manually whenever a new issue is opened. (and perhaps in the future the '...CUSTOMPAR1' part can be replaced as far as me the user is concerned with actual name that i define for it?). at least this has the potential to ensure that the project number makes it to the file name because it presents a dialogue to be filled in for each and every file using it as a template, (and people love filling in boxes, right?! ). globally changing the published items naming rules relies on remembering a manual intervention in each and every project using the template.

~/b

[Gerry Leonor]

+1 on changing the System Date/Time to match the previously issued dates. i changed the system date/time as needed, then closed the issue, then remembered to change it back. fortunately for me, i only had to deal with 1 previously published issue. but that certainly worked for me.

hoping a proper fix is applied soon.

[Paul King]

Gergely wrote:
About Issue Date:
this is precisely why we included the custom fields in the Issue / Change, so you can add any data to them, and list that data both in the Revision History / in the project indexes / autotexts.


About Revision IDs: see my other reply here.

If a need to edit any one date triggers a requirement to manually add/edit ALL dates, this entirely defeats the purpose of automation.

We need the ability to individually override past dates, revision ID, descriptions etc, e.g when a user mistake is found from two issues ago, but for any new information to be automatically added and correct

[__archiben]

Create a custom Issue Scheme for any autotext you want to control and appear by-sheet (rather than by-project).

[Paul King]

~/archiben wrote:
Create a custom Issue Scheme for any autotext you want to control and appear by-sheet (rather than by-project).

Thanks Ben. Would doing this once a project has already been issued several times already not then trigger the problem I was hoping to avoid though? (i.e. the need to go back and manually populate past revision dates, and manually populate new ones thereafter?

I am thinking in particular of the resulting drawing register document - the revision date column will need to be populated by either system issue date or manual custom issue date - not sure of any way to tell ArchiCAD to automatically know when to switch from one to another and back again as it goes down the page