Tinderbox Forum

Intrinsic user attributes and "unarchiving" notes

Hi all. I use Tinderbox as a task manager. I have a task prototype, and I have a stamp that moves tasks into an archive container. The thing is, I want to be able to unarchive tasks that were archived by mistake. So I have created a user attribute $OldContainer, where I save the $Container that a note was in when it was archived. The code to archive then looks like

$OldContainer = $Container;
$Container = "/Task Archive/"

Unarchiving a note is then fairly simple:

$Container = $OldContainer

However, I often work with aliases of tasks rather than tasks themselves. For example, I will take notes during a meeting, placing tasks inline as I go, and then put an agent that harvests all tasks in the outline at the top of the outline, and work from there.

Now, since $OldContainer is a user attribute, I cannot make it intrinsic, which means that a task must share its $OldContainer value with all its aliases. This makes unarchiving a task and its alias to their original containers impossible. For example, say we have the outline


  • task1
  • task1

If I archive the alias task1 and then archive the original task1, the $OldContainer for both notes will be set to “container1”. If I then unarchive task1, it will get put into container1, rather than container2 — the container it was in when it was archived.

Is there a nice solution to this?

Why can’t you create user-defined intrinsic attributes anyway?

Thanks for your insights!

Intrinsic user attributes are exotic: most people don’t really need to know much (or anything) about them.

But this is a fairly compelling scenario. In practice, I think most people who have agents creating those aliases, and those agents would be designed to ignore archived notes. So, archiving a note would remove all those aliases, and unarchiving it would recreate the aliases.

Nonetheless, there are situations where you can classify notes but an agent cannot, and there your example is compelling. We’ll try to allow intrinsic user attributes in the not-too-distant future.

That’s great news!

Yes, this is an interesting case where I might be interested in archiving only the alias and leaving the original in place as part of the meeting record.


Why specifically an alias in these containers as opposed to an attribute value or a link? Is this a visualisation issue - if you can’t see you might not know? As stated above, an agent might no know where you had aliases but you do. It seems to me you’re archiving aliases (alongside their original notes, on a presumption that the fact you have that alias will tell you where it once was (except it doesn’t).

Aliases are the same except for a few intrinsic structural (e.g. $Path) or visualisation attributes (e.g. $Width - but not $Color). Given the alases are just the same, why archive them at all? If you re-need an alias of a a task in ‘container2’ surely it is simpler. You’re (re-)adding the alias because you know you want one there. Whether it’s an existing (archived) one or a new one is moot. What you may actually find useful is to either both, store a list of containers that held aliases and/or the reverse where containers hold a list of aliases placed within them. These lists might be kept discrete from where the original task lived or the two might be mixed (there’s insufficient evidence given to decide that).

Hi Mark,

In my specific use case, I have tasks scattered through an outline, and I want to see a list of tasks at the top of the outline.

I generally want to archive the alias, and leave the original in place within the outline as a contextual record that the task was created and completed.

I do want the alias will tell me where it once was, which it will do, but only if the original or any of its other aliases have not been archived.

Mainly so that the list of tasks can be cleaned up without deleting the aliases, which carries the risk of accidentally deleting them and having to recreate the whole list again. Or it may be that archiving the alias becomes a more complex action, which sets some interesting attributes of the original note, but still (as I desire here) keeps the original note in place. In this case unarchiving would likewise become a more complex action.

At this point it’s just a matter of convenience (though if archiving becomes more complex this might not remain true). I archive an alias, then a bit later I realize that I didn’t want to archive it. Yes I can just recreate the alias, but it might be much easier to just go to the archive and unarchive the latest addition to the container. Now what if I accidentally archived three aliases in a list of ten? Unarchiving becomes much easier than recreating the aliases.

Hmm interesting idea. I’ll think about this — thanks!

Thanks, that gives some useful background.

Given the “…but only if…” qualification I read the first as a false positive rather than a success.

Short of intrinsic user attributes (as discussed up thread) I don’t see a solution beyond whats been already mentioned. Good luck!

Indeed :frowning:

Yes, so far nothing has occurred to me that is not hilariously convoluted.

Hopefully intrinsic user attributes will not be long in coming. I’ll work around it in the mean time — it’s not a disaster.

1 Like