Testing the Multi Wiki Server Plugin

Maybe an admin panel would be better suited for this? I would be concerned about cluttering up this main page too much – and I don’t think it would be necessary for all users to have this knowledge. Thoughts?

Can you clarify what you mean by this?

Recipes already show the bags that are in them

And I am proposing recipes with which a bag are associated should be listed beneath them

So what additional filtering would you like to see?

  1. "Show me only bags that are associated with this recipe?"
    Is there any reason why this would be superior than just looking at the recipe list?

  2. "Show me only recipes that are associated with this bag?"
    Why would this be superior to just checking the associated recipes list?

The only thing I could imagine might be beneficial would be filtering for multiple bags in a recipe, like, show me only recipes that contain A and B but not C – though I’d be interested in hearing more about the scenario this would be called for which could not be handled better with administrative levels.

In a similar vein, I wonder if it would not be sufficient to include list-sorting, so the user could, for example, sort by number of recipes to which a bag is associated? Low to high, therefore, first showing bags included in no recipes.

I don’t believe there is anything inherently “orphaned” (though I certainly understand your choice of word) about having bags that have no recipes - especially if moving multiple tiddlers between bags is easy, someone might want to have repository bags that they could shuffle tiddlers in and out of, which would be associated with no recipes – and that could be especially helpful if some of those bags contain large media files, for example, or time-sensitive content such as in the case of coursework.

1 Like

This is only true for “public” recipes. An owner should be able to define, if a recipe is visible to others. The same is true for bags. Otherwise it would be a privacy issue.

1 Like

I could imagine a tiered administrative system where if you have access to a level you could be given permissions to see the owners of other wikis in your tier and/or beneath your tier. I would need to put more thought into the bigger picture of wiki administration, since my current needs are not especially broad in that sense.

If I understand @JanJo 's use case though, I think they would have a good perspective on this.

1 Like

I guess administrative Tools like that become absolutely necessary given a certaike number of users. @jeremyruston How do you treat these questions at anna freud?

Now that I’ve got delete, filter tiddlers, and move tiddlers between bags, I’ve made another attempt using my primary wiki and noticed, when I tried to log in on a second device, it logged me out of my first device. Is this default behavior, or a bug that I’ve stumbled across? Anyone else getting this?

I could definitely see this being helpful in some cases, and it might even be a good option to implement in one’s account settings… however, it would be a bit of a pain for me as an every-time thing.

From my point of view that’s a bug. Since it should be mulit-user, multi-device it should work with the same user an several devices too.

Same as if you would access gmail from 2 devices at the same time

1 Like

I think this is definitely a bug (although I agree it could be useful behaviour in some situations). I’ve made a ticket here:

Anna Freud use Xememex, a multi-user implementation of bags and recipes for TiddlyWiki that I developed in 2016/17. It is based on Amazon Web Services and the serverless architecture. It has a separate admin screen with the ability to list and modify bags, recipes, spaces and users. There will be something similar for MWS in due course.

5 Likes

Some further testing confirms that moving tiddlers between bags has no effect on how their bag value is displayed (I didn’t really expect it to, since I didn’t tell it to do that when I set up the button, but thought it worth confirming).

My question is – when we move from a source-bag to a target-bag, should we update the bag field of each tiddler to the value of target-bag? Is it truly vestigial at this point, or is there some intention for it in the future?

My instinct on this is to update the value so that when it’s displayed in the wiki someone could reference its origin – as long as that wont interfere with any bigger-picture plans down the line.

1 Like

Hi @well-noted where are you seeing a “bag” field?

I’m talking about the bag field in the tiddler info, within the wiki.

These are my old tiddlers rather than newly created ones, so it could just be a value that’s carried over.

I could imagine times where one might want to be able to filter within wiki by source bag, which is what got me wondering if it should be included in the move-betwren-bags operation

1 Like

I think that is what has happened. MWS itself doesn’t use a bag field, but it was used by some earlier TiddlyWiki-based server systems such as TiddlyWeb/TiddlySpace.

Got it, was chasing my own tail :smiley:

Thoughts (anybody?) on introducing the bag field to tiddlers when they are created moved into MWS bags? The architecture is already there to keep the field hidden, and it would be simple to instruct that the the database update the bag-field when tiddlers are created or moved.

I can imagine client-side situations where, inside the wiki, one might want to group tiddlers according to the bags to which they belong – and while that could be achieved through adding some other tag or field, it seems to me that bag is a value that already exists and might as well be utilized.

My current single-file setup with Apache and WebDAV serves me well and is such that access requires no noticeable authentication

  • from my home (IPv4 and 6) addresses
  • or from my devices which use a key in the URI (shortcuts on mobile devices’ home screens)
    otherwise can use HTTP authentication (for use on any other random computer/location)

The configuration has this

    <RequireAny>
    Require ip a.b.c.d 2a0d:blah:blah/48
    Require expr "%{QUERY_STRING} == 'somethingorother'"
    Require user myusername
    </RequireAny>

Is there a neat way to do this with MWS or does it have to be coded up ?

Ta,

Jon

2 Likes

Hi @well-noted the earlier TiddlyWeb server side did rely on a “bag” field, and it turned out to be quite inconvenient, and lead to extraneous, unwanted bag fields on any tiddler that had ever been synced to the server.

In MWS, the client side sync process use two JSON state tiddlers to track the server side revision and bag of all known tiddlers:

  • $:/state/multiwikiclient/tiddlers/bag contains the bag names
  • $:/state/multiwikiclient/tiddlers/revision contains the revision numbers

This information can be accessed using the index syntax (eg {{$:/state/multiwikiclient/tiddlers/bag##HelloThere}}) or via the JSON operators.

As I think we’ve discussed elsewhere, moving a tiddler between bags would currently require two separate API calls. I would like to explore approaches that would let us perform that operation in a single API call.

Hi @jms19 MWS currently only supports form-based authentication with session cookies. Authentication schemes are not currently pluggable but the intention is that it will be possible to extend the built-in authenticators with custom ones which could handle the schemes you mention.

In the meantime, you may be able to use an external program such as nginx to implement the IP address-based authorisation.

I have been noticing something recently that suggests to me I may have a misunderstanding of MWS – discrepancies between the same tiddler when it is represented in different recipes.

For example, my TODO items are in one bag that is shared between two recipes – in one recipe, I tag an item as “Done” and am surprised to find that it is not also tagged as done in the context of the other recipe.

After some investigating, I discover that by changing the tag in one context, it creates a new tiddler in the top bag of the recipe to be used in the place of the same tiddler in the bag of lower items in the recipe.

Is this expected/desired behavior?

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

That’s desired behaviour.

You may have a closer look at a reply at an other thread, where I do point out some “gotchas” for new users.

Cloning content into “higher level” bags has an advantage in the long run. – The main problem at the moment is, that we do not have any visual indication, what’s going on.

If you would have had the possibility to move the “new tiddler” and “overwrite” the “lower level” one in a convenient and visible way, it would have been an obvious feature.

Because we are still in early stages, it is an issue.

1 Like

Could this be cured with an overwritten tiddlers table where the overwritten tiddlers are listed per bag perhaps with a sort of automatized temporary renaming mechanism.

(Zut alors ! It sounded easy in the beginning….)

Interesting. I will need to get my head around this somewhat.

In my case, I would like to have a general TODO list that stores all the TODOs from all my various wikis – it has access to all the bags of TODOs from the relevant recipes, and I had expected that I could interact with the TODO list and have those changes reflected across all the other recipes: instead, checking off a TODO item only generates a clone in the TODO List page template bag, which is not as useful to me, especially in the context of tracking projects.

I would propose going a step further and say allowing users to select from multiple handling depending on filter conditions would be most helpful.

For example, I don’t mind if my TODOs get shuffled into other bags, but ultimately I do want them to all aggregate toward the TODO-items bag.

Likewise, I want all my Index and Idea tiddlers to end up in my KnowledgeBase and my Sources to end up in my References.

State tiddlers are the only obvious example I can think of, in my case, for this, but perhaps I’ve overlooked something.