=====Hierarchies and inheritance===== >>**See also:** ForTheLazy - for a proposal for inheriting ACLs CategorySystemOverhaul - for various approaches to organizing pages>>A recent discussion on the [[TheLounge | #wikka channel]] brought up some really interesting issues about how wiki pages are organized, and how ACLs are determined. ::c:: ===Discussion log=== First, a copy of the relevant bit of the IRC discussion (with minor edits to remove some typos - but not Srekel's cat Klumpen, at his express request :)), followed by a few comments. %%(html4strict) Feb 02 17:46:01 hi all Feb 02 17:46:18 small note, ill post it on wiki later Feb 02 17:46:41 but if you secure a page using the ACL's, you can shield that page as you wish, works like a charm Feb 02 17:47:16 but, the pages you create under (look at it as a tree-structure) are using the default ACL's - meaning everyone has full access to it Feb 02 17:47:40 should they not use the ACL settings from their parents (the page they where created from) ? Feb 02 17:47:53 unless of course you explicitly say they should not use them. Feb 02 17:48:54 even further, should the children of a page nog always (unless, again explicitly told) use their parents ACL's dynamically .. Feb 02 17:49:02 hoi Freek Feb 02 17:49:07 lol hoi JavaWoman Feb 02 17:50:23 ummm - there really is no tree stucture in Wikka, so I'm not sure what you mean by "children" Feb 02 17:50:34 or parents Feb 02 17:51:08 well if you look at a tree from the roots, you can see the root as the parent (in a reversed tree) and the branches as children Feb 02 17:51:18 Ill look up a picture from google, one moment Feb 02 17:51:24 ..please Feb 02 17:51:27 a page in Wikka gets the default ACLs as set in the config - unless overridden by explicitly setting the ACLs to something else Feb 02 17:51:47 I know wtah a tree is - it just doesnt' apply to Wikka :) Feb 02 17:51:58 what (still can't type) Feb 02 17:52:48 Wikka is a network really, full real hypertext - no hierarchy at all Feb 02 17:52:48 http://www.adamsonhouse.com/xmllessons/Section2/page2.html Feb 02 17:53:12 its like a pyramid with parents on the top and children attached to it on lower levels Feb 02 17:53:27 ok Feb 02 17:53:33 yeah, that's what a tree is - it just doesn't apply to Wikka pages Feb 02 17:54:08 only (conceptually) to categories if you want to have subcategories - when you forget for a moment that they are now *implemented* as pages Feb 02 17:54:42 but if you only wish one private section in you whole wiki, you should be able to make this page use different ACL's Feb 02 17:54:52 pages just don't have any specific relationship to each other, any page can link to any other page Feb 02 17:54:55 but you might want everyting 'below' it use the same ACL's as well Feb 02 17:54:56 right? Feb 02 17:55:02 right Feb 02 17:55:15 there is no "below" :) Feb 02 17:55:23 category - maybe Feb 02 17:55:25 flat 'hyarchy' Feb 02 17:55:29 ok Feb 02 17:55:31 category's would work Feb 02 17:56:02 I could *imagine* a category system that has ACLs attached to it - but that's not how things work right now Feb 02 17:56:07 so you will have to add a different (new) category and add the pages you wich to be included to that category Feb 02 17:56:36 yes, you can do that - but there is no mechanism to "inherit" ACLs Feb 02 17:56:38 .. and provide category wide ACLs Feb 02 17:56:52 ok, thats fine if its possible this way Feb 02 17:56:56 I guess it could be done though Feb 02 17:57:19 I guess what Freek_NL wants is that when you click on a new WikaPage for the first time (i.e. you have written a link with its name, but you haven't created it), the WikaPage gets the same permissions as the page on which you clicked the link Feb 02 17:57:33 we've also discussed that the /clone handler should make the new page inherit the coned page's ACLS Feb 02 17:57:53 that sounds like a good idea Feb 02 17:58:04 yeah, Srekel , but that link could be on numerous pages already, al with different ACLs attached to them Feb 02 17:58:22 Srekel, yes, thats one way of doing it, but since I understand there is no hyarchy (all files seemed to be stored as flat files with no relation to one another) this is impossible. Feb 02 17:58:52 no, I can imagine two things (neither implemented now): Feb 02 17:58:56 but if you could create ACL's for one category and add pages to it (manualy) this would be fine as well Feb 02 17:59:06 JavaWoman, yeah, but it wouldn't be hard to just send along the ACL of the page the user clicked on (ignoring the other ones) Feb 02 17:59:32 Freek_NL, the fact that there isn't a hierarchy doesn't really matter (if you do it the way I suggested) Feb 02 17:59:34 1) apply ACLs to a category and have pages inherit from that - BUT note that a page can have multiple categories!) Feb 02 17:59:48 yes, becouse there is _some_ relation to the previous (parent) page... even if its only from the weblogs Feb 02 17:59:55 2) have the /clone handler create the new -page with the same ACLs as the template used Feb 02 18:00:02 true Feb 02 18:00:19 ok, so you cant use categories. Feb 02 18:00:28 but you can use groups Feb 02 18:00:39 or better 'roles' Feb 02 18:00:43 and groups ;-) Feb 02 18:01:06 gets more complicated this way, but should be able to be done not that hard in operation Feb 02 18:01:11 looking at 'linked from' won't work since as I said the "missing" page could be linked from many pages with different ACLs - it's a real network Feb 02 18:01:13 if there is a clear theory behind it.. Feb 02 18:02:13 what I could imagine is that when you *create* a page you get a number of options to set its initial ACL... Feb 02 18:02:15 JavaWoman, no, because you create a page only once. and if the ACL is copied from that page only (one time action - or sync) there is no interference with other pages' ACL's Feb 02 18:02:18 - from linked page Feb 02 18:02:22 - from category Feb 02 18:02:28 exactly Feb 02 18:02:31 - from template (when you're cloning Feb 02 18:02:34 that would solve most of the entire issue Feb 02 18:02:36 yes. Feb 02 18:03:06 one step further would be to enclude an option to 'keep in sync' with the parent (page wich it was created from) Feb 02 18:03:19 but you can create a page without doing any of those, just by typing the name in the URL and adding /edit to it.... Feb 02 18:03:25 yup, Freek_NL you understand what I mean now :) Feb 02 18:03:26 not to hard either i suppose Feb 02 18:03:53 * Freek_NL says an absolute noob on PHP, MYSQL and all programming languages.... Feb 02 18:04:03 :) Feb 02 18:04:21 it's not a programming issue though - it's a conceptual issue Feb 02 18:04:35 not all of it :-) Feb 02 18:05:28 well, implementation is - but the way Wikka (like most wikis) is structured that there _is_ no hierarchy Feb 02 18:05:42 but I do agree with your point JavaWoman that there is no (and may even) should not be a hierarchy Feb 02 18:05:56 so something to create a hierarchy will lead to kluges because the basic structure doesn't really support that Feb 02 18:06:18 and is not *desiged* to support a hierarchy Feb 02 18:06:51 well it can be designed to be compatible with some sort of hierarchy when you wish Feb 02 18:07:25 I think it should be done at the level of the 'child' Feb 02 18:07:37 yes ... but there are other Wikis that are designed to so this - some flat-file wikis store pages in a directory tree: automatic hierarchy Feb 02 18:08:01 the child should be able to say 'yes I want to be derived from my mommy' Feb 02 18:08:32 :) so the child should adopt the parent? at the very least it would require a change to the database, like a "parent" column in the pages table Feb 02 18:08:48 yes, but that does not work in the end because files can be linked to each other from various places and well, wiki's are flat by design (arent they) Feb 02 18:09:16 no, because everyone is or can be a child and parent Feb 02 18:09:17 you can have parents only if you store that in the database Feb 02 18:09:28 then an aunt could link to her sister's child :) Feb 02 18:09:44 but you could say that file X has n children namely: Feb 02 18:09:54 maybe you are right :-) Feb 02 18:10:12 incest? Feb 02 18:10:22 well incest aint that big of a deal in computing Feb 02 18:10:42 still tricky since even with just storing a parent you can get loops ad such, not a true hierarchy - that really requires a different database design Feb 02 18:11:17 you have (in unix) parent/child processes and children can have intimite relations including piping their in and output to each other... Feb 02 18:11:26 they can even kill theirselves and family Feb 02 18:11:44 yes, but don't the children know who their parents are? Feb 02 18:11:54 yes they do Feb 02 18:12:07 and can a process be "linked to " from several others? Feb 02 18:12:15 they are connected to children and parents (wich every 'object' can have) Feb 02 18:12:32 so it's a true hierarchy - not a network Feb 02 18:12:51 not linked but their status (current parrent and children) can be observed by other processes wich can thus take that in account Feb 02 18:12:55 you have a different data structure in that situation Feb 02 18:12:56 yes Feb 02 18:13:11 yes, but I believe it is possible in this case as well Feb 02 18:13:14 Wikka is *designed* to be a network Feb 02 18:13:27 but yes you would need to change some stuff in the database Feb 02 18:13:29 and its data structure reflects that Feb 02 18:13:57 but this would only be "file x is my parent (there can only be one parent=creator) and x,c and e are my children) Feb 02 18:13:59 thats all Feb 02 18:14:09 that's because the concept of HYPERlink is at its root Feb 02 18:14:22 the web is a network - not a hierarchy Feb 02 18:14:36 I know, but it does have parents and children Feb 02 18:14:42 everything is created once Feb 02 18:15:02 "created" does not mean it has a parent Feb 02 18:15:02 altered many times and might have been removed Feb 02 18:15:36 true but if there from, new objects are formed they do have parents Feb 02 18:16:25 no, an object does not need to have parent - and neither does a document, or - more general- a resource Feb 02 18:16:29 meaning (also practicaly) that the relations can start when a new object is formed Feb 02 18:16:41 but sometimes it does Feb 02 18:16:54 no - think again - there can be a link *already* from many different pages Feb 02 18:17:02 before it's created Feb 02 18:17:11 and if the child gets the oppertunity to say "I love my mommy and I want to be related to her" that should be possible Feb 02 18:17:35 the true "parent" would be the creaTOR, not which page she happens to click on the link from Feb 02 18:17:43 yes, but thats why you should let the child decide whether they want to belong to someone Feb 02 18:18:13 why should a child *want* to belong to another page? Feb 02 18:18:17 true, and the createor decides what should hapen Feb 02 18:18:27 because the creator wants it that way Feb 02 18:18:35 of if he/she does not, she can choos not to Feb 02 18:18:42 and what if the creator doesn't? Feb 02 18:18:59 a hierarchy is more limiting than a network... Feb 02 18:19:23 they say "I dont want to belong to mom, I think I can stand my man" Feb 02 18:19:47 sorry for over simplification, no offence meant Feb 02 18:19:55 (That's precisely why I can't really relate to mind mapping apps - they all want a hierarchy - and I just don't think that way) Feb 02 18:20:26 I can imagine, I live in total chaos as well ;-) Feb 02 18:20:33 but if you could combine those Feb 02 18:20:55 network != chaos... Feb 02 18:20:58 use for example the advantages from a mind mapping tool with our inner chaos - why the hell not Feb 02 18:21:09 use a structure where handy Feb 02 18:21:12 and dont where its not Feb 02 18:21:15 if I were a page I wouldn't even WANT to have to choose - I'm me and that's enough Feb 02 18:21:45 You wont want a choice? Feb 02 18:22:07 I have no inner chaos - but I do have an inner network - that's why those tree-based mind mappers don't "fit" MY mind Feb 02 18:22:10 I would like (in general and if I where a page too) Feb 02 18:22:15 no, I don't want a choice Feb 02 18:22:29 I don't wnat to have to *make* a choice, that is Feb 02 18:22:54 Srekel, would you like to have a choice? Feb 02 18:23:13 if you have the choice you dont have to configure the acl's all over again Feb 02 18:23:32 .. derived from the standpoint of being lazy Feb 02 18:23:54 ah, but you can "inherit" ACLs without needing to have a parent.... Feb 02 18:24:41 except there's nothing to inherit *from* if you create a page by creating a URL Feb 02 18:24:48 we shall await the wisdom of the Srekel Feb 02 18:25:18 true Feb 02 18:25:31 (Srekel is now consulting the Orakel....) Feb 02 18:25:37 so you would only need to have the option to chose once (upon creation) Feb 02 18:26:34 It _is_ a good idea to be able to "choose" ACLs immediately on creation of a page rather than having to go back and change if needed Feb 02 18:27:09 shall we wait till Srekel has consulted the infinit wisdom of the Orakle ? Feb 02 18:27:20 (Srekel is now fighting Klumpen again, I guess) Feb 02 18:27:33 (Klumpen is Srekel's cat) Feb 02 18:27:38 :) Feb 02 18:27:52 ping Srekel ! Feb 02 18:27:57 lmao Feb 02 18:28:30 You'll get less of a response out of ChanServ, I guess Feb 02 18:31:49 however I am making great use of Wikka. Feb 02 18:31:56 * Freek_NL has found his wiki! Feb 02 18:32:11 now that's good to hear :) Feb 02 18:32:17 JavaWoman, and I still think those ACL's are sweeeet Feb 02 18:32:23 just get used to it being a network then ... Feb 02 18:32:24 gj girl Feb 02 18:32:32 ....... Feb 02 18:32:45 we are still awaiting the response of your ping Feb 02 18:32:54 and Srekel s verdict Feb 02 18:33:17 Well, with the old Greek Oracle it could take days, I understand.... Feb 02 18:34:02 or maybe Srekel is off solving that permission problem he has on the school's server ;-) Feb 02 18:34:41 or maybe the firewall is blocking the ping echo? Feb 02 18:34:57 * JavaWoman has been configuring her new firewall ... Feb 02 19:18:16 hey, back Feb 02 19:18:23 lemme read what you've said Feb 02 19:20:36 back Feb 02 19:20:45 cool, thanks Feb 02 19:22:33 ok, so you wanna know how I would like ACLs handled? Feb 02 19:23:30 well, for starters I would like to know whether you would like to have a choice or not Feb 02 19:23:35 read that part? Feb 02 19:24:07 starting somewhere around: if I were a page I wouldn't even WANT to have to choose - I'm me and that's enough Feb 02 19:24:30 I say I do..., would you? Feb 02 19:24:34 I read it, but I'm not sure what you mean :) the choice to set the ACL to the "parent"'s ACL? Feb 02 19:27:53 well my point is that _some_ hierarchy would be usefull Feb 02 19:28:28 and one way to implement that is to let a page wich is newly created have the option to inheratage its 'parents' ACL Feb 02 19:28:52 parent = document where its linked from Feb 02 19:29:41 anyways, the point is wheather one _should_ have the option to assign ACL's to a newly created document - copying the ACL setting from its parents Feb 02 19:29:55 do you understand what I mean with the 'child' 'parent' thing? Feb 02 19:31:18 How I understand JavaWoman her point of view is that wiki's (Wikka) should not use _any_ hierarchy, for its not designed for that and should not be, thus she support a 'flat' way of storage (as far as i understand her point of view) Feb 02 19:32:24 no, I'm just saying that Wikka *is* designed that way Feb 02 19:32:39 I agree that there should be no hierarchy in a wiki. but, that doesn't change the fact that you can let a page "inherit" the ACL value of the page that linked to it Feb 02 19:32:47 while there are other wikis that are designed to support a hierarchy Feb 02 19:32:58 each system has a different data model Feb 02 19:33:37 a hierarchy cannot support a network and vice vera - not without kluges which wil bite you at some later time Feb 02 19:34:04 a simple copy-paste of ACL from the originating page. after that, they won't have any kind of relationship Feb 02 19:34:14 I agree with Srekel - hierarchy is something different than "inheriting" ACLs Feb 02 19:36:12 true Feb 02 19:36:22 so basically you can inherritage, but only once Feb 02 19:36:42 thus not dynamically linking ACL's for you would create some hierarchy Feb 02 19:37:39 right? Feb 02 19:38:00 right - which boils down to simply having a choice for which ACLs to create at the moment you create a page - Feb 02 19:38:09 but, so yes, I would like an option to "inherit" the ACL or to set it to the standard found in the config file Feb 02 19:38:17 which in its turn depends on *how* you create that page Feb 02 19:38:25 yeah Feb 02 19:38:50 the default for a page that is created just by adding/edit is of course (?) reading from the default config Feb 02 19:39:01 yup Feb 02 19:39:20 true, so you would need the option to inheritage it fromt a 'parent' Feb 02 19:39:32 ...instead of from the default Feb 02 19:40:00 but I could imaginge an etra bit in the edit interface (or /clone handler) when creating a new page that gives you the choice to set the ACLs differently, rather than creating first and then having to go back to adjust the ACLs Feb 02 19:41:24 so you would implement this feature on 'child' level Feb 02 19:41:34 on the level of the page wich is created, not where its created from Feb 02 19:41:51 exactly Feb 02 19:42:15 so we all agree on this ? Feb 02 19:42:16 because when you create a page by creating a URL - there really is nowhere it's created "from" Feb 02 19:42:30 indeed, it just has a creator Feb 02 19:42:50 wich is already nicely dealt with Feb 02 19:42:53 - the owner- who has to decide what ACLs to assign Feb 02 19:43:18 right, thats the most natural way to do this as well in my opinion Feb 02 19:43:35 it just would be handy to do it at the same time as creating the page, rather than as an extra action Feb 02 19:43:54 both Feb 02 19:43:59 right Feb 02 19:44:43 Srekel ? Feb 02 19:44:45 not both, sorry Feb 02 19:44:50 not possible Feb 02 19:44:58 JavaWoman, yes? Feb 02 19:45:11 your opinion on this? Feb 02 19:45:22 (or are you fighting Klumpen again?) Feb 02 19:45:33 lol Feb 02 19:46:11 lol :) no, was talking on the phone :) Feb 02 19:46:28 well, it sounds good to me Feb 02 19:47:45 I could put this stuff on the wiki somewhere Feb 02 19:48:00 sure, write it up... Feb 02 19:48:30 Ill write the story and youl code it? ;-) Feb 02 19:48:37 it might be a page on its own, and we could link to it from several places ;-) (so it won't have a parent...) Feb 02 19:48:49 haha :) Feb 02 19:49:15 Ill be the parent... bit young though ;-) Feb 02 19:49:21 before I can code ANYTHING I need to get Alan back to working order... - and then I have a load of catching up to do Feb 02 19:49:31 20 and daddy already Feb 02 19:49:52 just kidding Feb 02 19:50:08 but yes, I could see a way to do it that doesn't get in the way of people who just want the default but allows an options for those who want a different set of ACLs right at page creation time Feb 02 19:50:21 lol! Feb 02 19:50:38 go ahead and start a page... Feb 02 19:51:10 wat is een goeie afkorting om weer te geven dat je nog wat moppert, moed verzamelt en langzaam aanstalte maakt? Feb 02 19:51:10 * Srekel is proud of his son Klumpen Feb 02 19:51:19 LOL Feb 02 19:51:42 nwmmveam? Feb 02 19:51:44 he's so good at removing the magnets from the refridgerator :) Feb 02 19:51:57 splorf! Feb 02 19:52:36 (I get a lively mental image at that...) Feb 02 19:55:51 where would I add info like this? is there a development area just for idea's or feature propositions? Feb 02 19:55:58 or shall I add it to the mainpage ;-) Feb 02 19:56:57 haha, I bet :) Feb 02 19:57:07 no, there isn't really an area that fits, except SuggestionBox - but I think it should have a discussion page on its own (given the discussion we just had...); which you could then link to *from* the SuggestionBox Feb 02 19:57:32 cool, thanks %% ===Discussion and conclusions=== ==Organization of pages== A really important aspect of this discussion deals with how one organizes pages in a Wiki: ~-As a "network" structure where any page can be related (linked) to any other ~-As an extension of that, a system where a page can belong to one or more [[CategorySystemOverhaul | categories]] ~-In a hierarchy, where a page can have //one// other page as its "parent" How one wants to organize pages in a Wiki has important consequences for the design of the data structure to store the pages. In general, a flat-file storage system, where each page is a file in the file stystem, lends itself very well to a hierarchical structure by storing pages in directories and subdirectories. When pages are stored in a database table, a hierarchy can be accomplished only by storing "meta" data along with the pages to indicate and maintain the parent-child relationships. While a database design that supports a hierarchy could conceivably support a pure network (by never assigning any page to a parent), the inverse is not true: a database that is designed only to support a network and doesn't have the data structures to describe a hierarchy cannot easily be adapted to support one. Most Wiki engines are designed for a pure **hyperlinking** network. Like most wikis, Wikka's database design is intended for a pure network; a hierarchy would require a major redesign or extension of the database. **If your application requires a hierarchy, WikkaWiki is not the wiki engine for you**: there are other wiki engines that are designed to support a hierarchical structure of the pages in it. ==ACLs and "inheritance"== When a new page is created in Wikka, it gets its ACLs (permissions for reading, writing and commenting) from the default as set in the configuration; as long as the ACLs for the page aren't edited, the default ACLs apply, even if those defaults are changed by the WikiAdmin after the creation of a page. The page creator becomes page owner; if (s)he wants to set **specific** permissions for a page, (s)he will have to go back to the newly-created page to change the ACLs (only [[WikiAdmin]]s and page owners can do that). In a hierarchical system, "inheriting" ACLs from the parent page would be natural; in a network system it's not that easy: a "missing" page can already be linked to from different pages, each with different ACLs, before it gets created from one of the links. Still, the idea of "inheriting" ACLs at the time of page creation is an attractive one. ==Implementing ACL choice at page creation== To consider how this could be implemented in Wikka, we need to look at the various ways in which new pages can be created: ~1)By creating a URL with the new page name (and optionally immediately adding the /edit handler) ~1)By using the form presented by the "newpage" action ~1)By following a "missing page" link from another page and following the "create" link from the resulting dummy page ~1)By cloning from a template page ~1)By cloning from another (non-template) page ~& I've implemented a proof-of-concept patch that implements cases 4 & 5 [[BrianKoontz | here]]. --BrianKoontz It's clear that in case 1. there is no relationship at all with any other page; if you want to set ACLs at page-creation time, the only options are to accept the configured default or set ACLs to specific values; case 2. is nearly identical, although the newpage action could be modified to pass on the page it's sitting on so that page could be used to copy ACLs from. Case 3. provides a clear choice: "inherit" ACLs from the page it was linked from (and which link was followed), with the default settings as an alternative. Case 4. is actually very much like the newpage action: the template provides the content only but a template's ACLs could deliberately be very restrictive and not apply to pages cloned from it: only default ACL settings or setting them to specific values would be applicable. Case 5. again provides an opportunity for "inheritance" where the page cloned from would provide not only content but also ACLs, with configured defaults or specific settings as alternatives. ==Conclusion== In conclusion, it seems quite doable to provide a choice for setting ACLs at page creation time in Wikka, where the choices (logically) depend on what technnique is used to create a new page. If a page creator wants ACLs that are different from the configured system defaults, this would make page creation a one-step process instead of a two-step one. ===Comments=== Further comments are welcome, of course. ~& Ouch! It took me quite an effort to read you through this long conversation, with Klumpen messing up things every two lines :-) Anyway, here's my 2 cents. I think a big part of the above discussion suffers from a confusion between the idea of //X linking to Y// and the idea of //X being father of Y//, which are really two different relations and should not be conflated. I definitely agree with JW's argument that Wikka is **flat** (it's a ''graph'') and wouldn't survive an operation aiming to force its structure into that of a ''tree'' (trees are a specyfic kinds of graphs with a number of formal properties that we don't really want to impose to wikka). At the same time there are many ways of adding "soft" structure (like a "soft category system") to a graph. The current category system, for instance, creates a sort of soft hierarchy, as JW was pointing out, in the sense that it allows you to 'read' certain subgraphs of wikka as if they were trees, even if this soft structure has nothing to do with the underlying, "hard" structure. So I totally agree with the fact that "inheriting" should be seen as something related to users' operations and **not** to physical relations between pages. Now, do we think that the current system for setting ACLs is too poor/primitive? Well, there are many ways to make it more flexible, but they should all be based on //operations// rather than on //relations between pages//. For example, we might imagine user-configurable ACL defaults for different kinds of operations. I'm not sure whether this would be useful, but it's certainly implementable. Such defaults will establish the different kind of behavior ACLs will have when users perform different kinds of operation. --- Imagine I want: 1) every page I create from an URL to be set to DarTar, DarTar, DarTar as default 2) Every page I clone to be set to *, +, + and 3) every page I create from a missing page link to be set to the system default ACLs. This could easily be implemented as a set of user options overriding system defaults. But again, this is totally different from thinking that pages should be hardcoded in the DB as 'children' or 'fathers' or 'siblings' of other pages -- DarTar. ~~&Thank you DarTar - "**graph**" was the word I was looking for all the time. ;-) Sorry for the long post - but I thought it was interesting to show how the ideas about structure and hierachies evolved in this discussion which started by suggesting a need for a hierachy but ended up with what was really at the core of that idea: needing a mechanism for more immediately setting ACLs than we can do now. (And it may be interesting for people not frequenting our #wikka channel to get a taste of what's going on there (at times).) --- I like your idea of setting user options for default ACLs depending on page creation method. A different approach than I was thinking of, but probably easier to use. --JavaWoman ---- CategoryDevelopmentDiscussion