On Jun 8, 5:22 am, Oveek <[email protected]> wrote: > Knocking things down one by one. With the sqlstore available I feel > like I can create a test instance of TiddlyWeb at work. I think it's > going to be pretty awesome once all the pieces come together.
Just out of curiosity, why does the sqlstore change the work situation? > By the way I tried posting this as a comment on TiddlyWeb at peermore, > but the comment didn't get saved back to the server for some reason. I > thought I successfully posted a test comment a while ago, but this > time I just saw the comment get added locally without being saved on > peermore. I didn't see any http request in response to pressing Add > Comment. Ah. Yeah. Fixed. The reason that was happening was because while the TiddlyWebAdaptor is configured to send content to tiddlyweb.peermore.com, the javascript for doing it came from tiddlyweb.com, so the security constraints kick in. To get around this I've made tiddlyweb.com redirect to tiddlyweb.peermore.com for now. I may flip that at some point, depending on how we decide to front door the tiddlyweb web experience. > Well I'm now deciding how to manage users, roles, and policies. Before > getting to more general questions, I have a specific one. > > Is there a way to allow users to delete only tiddlers they themselves > created? Not really no. This, as you've surmised, is in conflict with the security model that presented by bags and policies: There are no controls that related to single tiddlers. This was a design choice early on. I can imagine ways to make such things possible: For example one could add 'AUTHOR' or 'MODIFIER' to the 'ANY' and 'NONE' special rules that exist for polices. If the delete policy had 'MODIFIER' in it, then the most recent modifier could delete it. I'm reluctant to do this sort of thing though as it involves more processing when doing any action, but wouldn't be the end of the world if there is demand for it. Or people could monkey patch it in if they wanted. > I anticipate people deleting other people's tiddlers as potentially > causing some unpleasant situations. I was recently called a "paleo-wiki type" which basically means I'm old school about wikis: There is no such thing as other people's tiddlers, there's only tiddlers that belong to the whole group. If there are issues with the group deleting stuff, then you have a social problem that no amount of technology is going to help, you're going to have to talk about it and work it out. That said, it occurs to me that DELETE of a tiddler in all of the stores that I know about (text, sqlstore, simpletext, devtext) remove the tiddler and all revisions irrevocably. It doesn't have to be like that. One could flag the tiddler deleted, but leave it in place, making deletes recoverable. My thinking on this matter is it should be up to the store what DELETE really means. > One way I can see is to give each user their own bag where only they > have delete priviliges. But then you have issues including all those bags in recipes (a plugin could address this for you). > I'm thinking this sort of thing doesn't fit very well in the current > policy scheme. It's messier because it seems to venture into the realm > of per tiddler permissions. Any ideas how this might be done? If the situation is that you want every user to have their own bag in which they can control their own stuff, but everyone can see all the stuff, my suggestion at this point would be to make plugin that enumerates all the users, gets the username and dynamically creates a recipe by appending all those username as bags, and then calls send_tiddlers(). You can look at the cachinhoster, dynarecipe and tiddly-editor plugins for examples that do similar things. I would guess, even hope, that your plugin would have your own unique style from which I might learn a ton. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
