Archived Journal Entry - Active Token on Map - Called Attribute "Bug"

So, there's a strange instance where a token on the map, assigned to a journal entry that has been archived, can lose access to its attributes when its name is changed. Confusing? Yep, but here's how to replicate the issue: Mook1: Build a 'mook' and link its token to its journal entry. Give it an attribute such as CMD. Mook2: Build another 'mook' and give it an Token Action ability that calls upon the first mook's attribute. For example, use: [[1d20]] vs [[@{target|CMD}]] ! In both these cases the exact attribute and ability are irrelevant; these are used only for example. The important part is that they are on the mook's journal entry. Correctly create tokens for each mook and place them on a map. Archive the character sheets for each mook. Using Mook2's token action, 'attack' Mook1. Everything should work properly, despite the journal entries for both being archived. On the token itself, without accessing the journal, change Mook1's token name. Using Mook2's token action, 'attack' Mook1. The system returns the response: "No attribute was found for targeted token by the name of CMD" The reason for this is that changing the name of the token for Mook1, has changed its "Represents Character" from "Mook1" to "None/Generic Token". If the journal entry for Mook1 is un-archived BEFORE the token's name is changed, this does not happen. To reiterate: Changing a token's name, when said token is linked to a journal entry that has been archived, un-links said token from said entry. This may not, in fact, be a 'bug' per se. It may be a deliberate design choice. However, it does limit the ability to pre-generate a scenario and archive the character sheets used to generate the tokens for that scenario, in that one has to un-archive the journal entries before re-naming the tokens. For example, I may set up a scenario with a dozen, let's say frogs (call-back to my previous bug thread!) scattered about on the map. Then, after archiving the journal entry for those frogs to reduce clutter, my players enter the scenario. To make the various frogs more easily distinguishable, I decide at this point to number them by re-naming the tokens from "Frog" to "Frog1", "Frog2", "Frog3" etc. If I forget to un-archive their journal entry, the tokens are 'broken' at this point and I have to re-build the scenario from scratch. In the big picture view of things, this is not all that substantial of a problem. I tend to push the abilities of Roll20 to their limits and do things the developers were not expecting to be done; this is an example of that. Nonetheless, I think this is something that could be 'fixed' (assuming it's not a deliberate design choice) and thought I'd bring it to y'all's attention! Keep up the good work, lemme know if you need any more information or help reproducing this 'bug' if that's what it is! -Phnord the Bug-Finder!

Correction / Addendum: A token representing a journal entry retains its connection to said entry despite said entry being archived UNTIL a change is made to the token's properties, regardless of what change is made. Example: Soldier Ant token placed on field; journal entry is not archived at this point. Soldier Ant has all Token Actions, as well as attributes and other properties, as desired. The token's "Edit Token" window is opened: Everything as expected. At this point, the Soldier Ant journal entry is archived, and everything is closed. The token on the map is re-selected, and its Edit Token window is opened: Note that "Represents Character" shows it as representing nothing; despite this, the token actions remain. The Soldier Ant continues to work perfectly at this point, IF THE EDIT WINDOW IS CLOSED WITHOUT SAVING. However, even if nothing is changed, if the Save Changes button is pressed, this is the result: Note that the Token Actions bar has disappeared. It seems as if the reason for this is, as would make sense, the Edit Token window can't access an archived journal entry. It doesn't matter, until some change is made in the Edit Token window. But once any change is made and saved, the token is saved as "None/Generic Token" and it loses its journal-linked properties. Again, not so much a bug as an expected issue, once I thought about it. I guess this can't be 'fixed' after all; it would seem to be a design choice. Nonetheless, let this be a warning to GMs out there who might run into this issue. Be careful! Not a criticism; Roll20 is a wonderful system. It is however full of little traps like this that we have to watch out for, when we push beyond its design limits! q;}