Support Ticket


Most wiki and cms systems allow the user to easily upload files that belong to a certain card. If that card is deleted, the uploaded files should be deleted as well.


This does not seem to be an easy task to setup in Wagn: it seems to involve a combination of embedding a plus card of type Pointer and then manually adding pointers to new cards of type 'File', that the user must remember to add with the right name - ie, adding a "+" at the beginning of the name.


I have not found a solution yet that is elegant, or that minimises the risk of the end user not committing a simple mistake, and end up uploading files that don't have any connection to any other cards.


I am a newbie, so perhaps I am missing something obvious - all guidance will be much appreciated.

I have a 'Client' card type. In each Client we should have an '+Attachments' section - a list of files that belong to the client file (scanned docs, pdfs, etc.). The end user should be able to upload files easily in a way that will display in a list, in the Client's card. Also, deleting the Client card should cause all attached files to be deleted as well.


I can see only one way to set this up: the 'Client+Attachments' is a card of type 'Pointer'. To add a new file to the list, the user edits the pointer, adding another card to the list. When the user adds a new card to the pointer list, this new card is added as a 'Basic' card by default, and the user then must select 'File' as the correct card type - there does not seem to be a way to let the pointer know that we want to add 'Files' by default. That in itself is annoying to the user, but the not the main problem: the user must remember that the name of the new File card must start with a '+' - otherwise it won't be 'connected' to the 'Client+Attachments' hierarchy... Users inevitably forget to add the '+', and then you have file cards, with files, uploaded all over the system, unrelated to any client.


Is there an 'elegant' way to accomplish this?


Granted Wagn's file-handling could be better, but it's not quite as bad as you describe...

  • You can default cards in a Pointer to be a certain type by adding in this case "Attachments"*right+*options" and putting in the WQL there:
    {"type": "File"}
  • I'm pretty sure there's a way to autoname the cards so that people dont have to name them before uploading, but I lack the time to re-figure that part out myself at the moment (gotta go mow the lawn), maybe someone else can chime in or you could explore it yourself and see how far you get - see autonaming. It might require a different card structure, which may also help with your desire for the files to be auto-deleted when the Client is deleted.

--John Abbe

Hrm, looked at it a little more just now and I'm not seeing an elegant way forward. I thought of using File+*type+autoname with "{{_user|name}}+file0001" but that does not work.


Anyone else?


People with an account on test can see what I tried:*type+*autoname (fails with: Can't save "{{_user|name}}+file0001".)


  --John Abbe.....2012-11-04 23:46:56 +0000

That's probably a bug, should be a bug report for it then.


But the basic idea is right. I think what is confusing is that with Wagn, you don't attach a File or Image to a card, it is a card. That gives a lot of power, but what it means is that to make an attachement, you will need to use the Wagn mechanism of a plus card, or alternatively a pointer card (probably still a plus card, but then you can have a list of images (cards) attached).


So, John's first point is that you make it so your attachement field (in John's rule, that is any card matching the pattern <some card>+Attachements). The autonaming thing is also possible, but a bit more tricky. John has either exposed a bug, or it needs a little tweaking.

  --Gerry Gleason.....2012-11-05 14:54:24 +0000

As far as deleting is concerned, when you delete a card, it checks first to see if it has referencers, which includes plus cards. It gives you a dialog where you can choose what you want to do (don't remove it, break the links, or delete references). Actually, I'm not sure it gives the last option, but I think it does or it should in some form). We are also working on an event system that could do arbitrary actions on the event of updates, deletes, etc. That will give more wagneering options on how this can be handled, and the out of the box defaults will be improved with this as well.

  --Gerry Gleason.....2012-11-05 15:09:12 +0000

Gerry, I forgot to escape the markup in my comment - fixed it now to show the actual error text. Not so much a bug as an un-implemented feature :-), anyway here's an Idea ticket for it: Interpret markup in names from plus-*autoname

  --John Abbe.....2012-11-05 16:16:28 +0000

A less-than-elegant way to handle this would be to not worry about having the File cards plussed to the Client card, and before deleting a Client delete their File cards by hand. You could easily get a list of them by making a Search card "client files+*right+*content" with this WQL:

{"found_by": "_self+*editing",

"type": "File",

"view": "open"


Then just go to "Client+client files" and you'll see a list of file cards they've edited and can easily go through and delete them.

  --John Abbe.....2012-11-05 17:06:32 +0000

In Wagn, Files are their own cards, and are much more flexible beasts than in most wikis. A given file can be connected to countless other cards. If you want to relate them to a client, then my first question would be "what is the relationship?"


If it's files edited by a client, then something like John's WQL would work (though the more natural wql would be to substitute the first like for "edited_by":"_self". For files created by a client, you could do similar WQL with "created_by":"_self".


You could also create a cardtype that is something like "assigned files" that have a +client value (which could be prepopulated in a link). And then you could replace the pointer idea above with a search for all files assigned to a given client. This is handy, because you could save a lot of grief in cases where a given file is assigned to many clients.


I agree that easy interface for attaching a list of autonamed files would be handy. We've discussed that, and I'm hoping we'll have something like that shortly after 2.0. I do know of a few other use cases. But I'm still of the mind that Wagn's approach has WAAAAY more long term potential than standard wiki attachments.

  --Ethan McCutchen.....2012-11-05 18:57:45 +0000


There is no question that Wagn's approach is wonderfully flexible. Despite its flexibility, however, there does not seem to be a way to address this use-case with the current feature set of Wagn.


The use-case seems to state:

a) The developer wants to be able to embed a list into a card, to which their user can arbitrarily add items (other cards), of a certain specific type.

b) when the 'parent' card is deleted, all sub-cards from the embedded list be automatically deleted as well.


It is currently possible for the developer to add a Pointer to a card, and specify the type of cards that will be added to the list, as mentioned above. This seems to solve requirement 'a'. However, in order to solve 'b', we need to be able to establish a true hierarchical relationship between the cards, and this can only be done with card names. Unless the user is 'helped' to autoname the card - 'linking' it to its parent - as mentioned by John above, requirement 'b' will not be fulfilled.


It seems to me, that this goes way beyond merely attaching files to a card. This design pattern is useful in a *very* wide variety of situations:


* adding 'Contact Logs' to a 'Client' (deleting Client must delete all Contact Logs)

* adding 'Charges' to an 'Invoice' (deleting Invoice must delete all Charges)

* adding 'Comments' to a 'Topic' (deleting Topic must delete all Comments)

* adding 'Contact Numbers' to a 'Supplier' (deleting Supplier must delete all Contact Numbers)


In all these situations, the embedded list will be of an arbitrary length, so it is not reasonable to add a pre-defined number of possible items in the parent card. Also, deleting the parent card *must* delete all its listed items, and it is not reasonable to expect the user to delete each entry manually, before deleting the parent.


I would be *very* interested in finding out from the more experienced developers here, if there is already a way to do this in Wagn.

  --Knud Potente.....2012-11-12 22:28:09 +0000

"...already a way to do this in Wagn?"


Short answer: no.


To confirm what's implied above, currently destroying triggers only one other class of cards to be destroyed: name dependents. A

"name dependent" in this definition is any card of whose name the current card's name is a part. So destroying either A or B destroys A+B. (notice that this is a little different from most trees, like file directories, in which /B has nothing to do with /A/B.


You define the problem very well and clearly, and I think we can come up with a robust solution by 2.0. To a Wagneer it would probably look something like a special edit view for pointers and a modification of our autonaming. To a normal user it would mean that when you click "add another", you just get the interface to create a new card.


If you were interested in considering paying for a modification like this, I'd be happy to put together a bid. First guess is that it would be in the $500-$1000 range.

  --Ethan McCutchen.....2012-11-12 23:15:16 +0000

I recall seeing a website once where people could announce software they'd like built, and they and others could make pledges until a developer looked at the total pledged and agreed to do it for that amount. This was before the recent "crowdsourcing" term/craze but I can't remember the name and a quick Google search failed to turn it up. If we can't find a tool like this, we could try to Wagneer such a thing...

  --John Abbe.....2012-11-12 23:48:18 +0000

see Dynamic wagn cards

  --John Abbe.....2013-03-13 09:57:00 +0000

We've talked about exactly that in the context of another project: Source Tree Commons. If Art will let me have the domain names, I would like to build out that project under the original name, if not, I can find another one.


What we really want is a Community of Practice with currencies infrastructure. All of that is my top priority after 2.0.

  --Gerry Gleason.....2013-03-13 10:59:40 +0000