#foswiki 2017-07-25,Tue

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood [00:52]
............... (idle for 1h10mn)
ChanServ sets mode: +o Lynnwood
geetar has left
[02:02]
......................................................... (idle for 4h42mn)
ChanServ sets mode: +o cdot [06:47]
..... (idle for 23mn)
TomAmbergHey howdy everyone from a guy in the Silicon Valley. I'm a new Foswiki implementer / developer (hack-level). Is this the best place to start discussion on desired features in Foswiki? [07:10]
***ChanServ sets mode: +o MichaelDaum [07:13]
MichaelDaumHi TomAmberg. You are at the right place actually, maybe at the wrong time, as lots of people are on vacation atm or very soon. [07:14]
TomAmbergOK, my first feature request, one that I kind-of implemented (without a GUI) in a local hack-version of Foswiki: [07:15]
MichaelDaumYou could also go to https://foswiki.org/Support/WebHome and click on "Ask a Support Question" [07:15]
TomAmbergREQUEST: have a page access mode that simply inherits all of its security aspects (view, editing, etc.) from that page's PARENT topic. [07:16]
MichaelDaumI've seen your Q on facebook as well. So you might also want to have a look at https://foswiki.org/Support/WikiConsultants.
wrt your idea: yes we have been pondering this kind of inheritance of access control a couple of times.
[07:16]
TomAmbergI would suggest that this would be a good "default" page access setting. This way the page access options just need to be applied when you need to make an exception on that particular page (or a new branch). I think this is a much clearer idea to users. [07:17]
MichaelDaummaybe, I am not quite convinced. [07:18]
TomAmbergOK, good to hear you are considering it - please count my request as a big up vote for it - it was so important to me that I started putting in some new code in topicACLaccess.pm to implement it. [07:19]
MichaelDaumtwo objections: (1) things will slow down considerably (2) the topic parent relation is quite fragile and could easily get lost somehow thus disclose the subtree accidentally [07:20]
TomAmberg(What I haven't been able to do yet is implement GUI changes in the edit.natedit.tmpl code...) [07:20]
MichaelDaumah interesting
(3) finding out why somebody was denied access may become a difficult task
these are the issues that I would consider in a more complicated mode of operations checking ACLs
[07:21]
TomAmbergI'm quite sure it could impact performance - the code I put into haveAccess looks for a new (for my implementation only) "USE_PARENT_TOPIC_ACCESS" flag in the page, and if that's set, it recursively calls haveAccess on the parent page. That could go up quite a few levels in a deep tree. [07:23]
MichaelDaumy
heh, so you are saying that depending on a USE_PARENT_TOPIC_ACCESS preference setting some topics follow ACL inheritance ... and some not?
[07:24]
TomAmbergBUT - with all these new nifty server microprocessors coming out, why not use available compute power (unless a better method can be found) to make the security model much easier for users who need to have tight sectionalized security?
In my simple implementation, definition of that flag just causes it to inherit. You don't want inheritance, don't define the flag. I realize this is a hack, from a Foswiki beginner....
[07:25]
MichaelDaumpoint taken. note however that we are operating in a range of about 500ms approximately [07:26]
TomAmbergI understand. Perhaps it is better to have a feature with a warning about performance, than not have the feature? [07:27]
MichaelDaumwell first, you don't really need to implement it in the core as this feature is pluggable
you may implement the new ACL module and set $Foswiki::cfg{AccessControl} to the appropriate class
[07:28]
TomAmbergBackground: this all comes from the desire to explain to organization management that Foswiki can be a "secure, with straightforward security settings" environment to put corporate data into. Hence I've done a lot of thought (and some hacking) to try to implement along such lines. Without being able to show security, and ease of use, management won't buy in. [07:29]
MichaelDaumI definitely like your approach. Yet I'd keep things modular from an implementation point of view. [07:30]
TomAmbergOh, yes, absolutely. I completely realize that my approach wasn't what an experienced Foswiki developer would do. [07:31]
MichaelDaumI see. Yet these kind of concerns wrt security is normally dealt with on the Web level covering all topics in it.
information policies in organizations vary a lot
[07:31]
TomAmbergFEATURE REQUEST NUMBER 2: (which comes from the same emphasis on secure, with straightforward security settings" environment) [07:32]
MichaelDaumorganizations normally tend to deny access to all information and only selectively open up those pots that an employee needs for his job ... as far as they know ahead what he/she will be requiring to have access [07:33]
TomAmbergPlease have the steps needed (mouse clicks, and where) to _view_ the security settings match mouse clicks (other than hitting an "edit button" to _change_ the security settings. [07:34]
MichaelDaumyea, this definitely is a good one. [07:34]
TomAmberg(That should have read "(other than hitting an "edit button") to _change_ the security settings.") [07:35]
MichaelDaumunderstood: you 'd like to _see_ the current security settings. [07:35]
TomAmbergThe GUI for viewing settings and changing settings don't seem to match. To have them match would make the usage flow seem much more natural.
Yup. See them, and then with a simple "edit" click (and I realize that may force a revision of the whole page) simply edit them.
[07:35]
MichaelDaumfoswiki's acls are hierarchical already in two respects: (1) location of object (2) nested user groups
so viewing and editing _is_ asymetric by nature
[07:37]
TomAmbergGoing back to what you mentioned as where security settings are implemented, yes, I can see that for some orgs / projects, setting them at the "Web" level makes sense. HOWEVER.... for some situations, they don't. [07:39]
MichaelDaumbasically webs make most sense when planning ahead for an information policy [07:40]
TomAmbergFor example, here in the Silicon Valley, we may have a web for an overall company team, but some of the projects within that team may be needed to be kept secret except for select members of that team. This happens a lot when a customer of your org calls on you to support something that is very secret to them.
OR, you may want to bring contract engineers in, and you need to let them have access to some info, but not "the crown jewels".
[07:40]
MichaelDaumthats quite common [07:42]
TomAmbergThe way I wrapped my head around the "wiki vs. webs vs. topics" organization, is that I think of a wiki site as a company campus, with the webs representing different buildings - some people just NEVER go into certain buildings, because it just makes no sense - and the topics are rooms or hallways within a building.
We often have limitations to only certain people having access to certain hallways - so creating straightforward ways to implement likewise in Foswiki would be good.
[07:43]
MichaelDaumyea good picture. yet some projects span multiple units. [07:44]
TomAmbergYes. It can get confusing trying to map this to a wiki structure. Hence my going into "Rodan Thinker" mode on Foswiki & security.... [07:45]
MichaelDaumbuilding webs along the organizational structure _might_ look like the first best thing to do
and for a lot of setups this _is_ the best thing to do as people will understand the site this way easier... including its information policy
[07:45]
TomAmbergYup. That's the first step. But then (in the last org I was in) we were finding that different projects being done for different customers required isolation of data. [07:47]
MichaelDaumright. and then you start creating subject matter webs ... which too is a valid approach, yet a different one, to webs.
I personally try to avoid cerating so many webs: they are information silos.
[07:47]
TomAmbergI think what you lose, when you put things into different webs, it the ability for "we can see everything" people in the org (i.e. management, or key engineers) is to be able to look at the tree, and see EVERYTHING going on in the organization. [07:49]
MichaelDaum^snap [07:49]
TomAmbergYes, I agree with your "information silos" analogy. Yet sometimes you can't help but _have_ to create them. People in the Silicon Valley are quite paranoid when they need to work with partner companies! [07:50]
MichaelDaumI rather like organizations to trust people. you can still hide the few crown jewels in a special silo of its own. [07:51]
TomAmbergYes, it would be nice. I just would like to have the silos be branches in the unified web for organization, rather than being off in a separate web.
(Hence the whole inheritance concept.)
[07:52]
MichaelDaumthis is way better in everyday operations as people don't hit the access denied wall all the time ... which in the end discourages people to share information or be commited to their work, let alone be willing to share their information as well.
another way to structure information is using Categories instead of webs.
[07:52]
TomAmbergWell, I'm hoping that with a good tree organization, that people won't hit access denied walls, because they don't even try to go view a page. Think of it as "Chip Design Team Web -> Project1ThatEveryoneKnowsAbout / Proj2ThatEveryoneKnowsAbout / Proj3ThatIsSecretExceptForTwoGuysWorkingOnIt
That "Proj3ThatIsSecretExceptForTwoGuysWorkingOnIt" link would ONLY be seen by the two guys.
[07:54]
MichaelDaumsee https://foswiki.org/Extensions/ClassificationPlugin for an implementation of a taxonomy system
it once followed the idea of transporting access control along the category tree.
[07:55]
TomAmbergOK, I'll take a look at Categories and taxonomy. I still like a good straightforward tree. That's why my next thing to do is find out how to have all the pages that are direct (1st gen) children of the page you are looking at show up at the bottom of the current page.
(er, links for the 1st gen children, not the page info itself.)
[07:57]
MichaelDaumhey good discussion.
feel free to drop in here and we can continue it as you like.
[07:58]
TomAmbergIN other words, I want to make the tree organization aspect of any given web REALLY apparent to all users. I think Foswiki already has the capacity for this, I just need to learn how to make templates...
OK, thanks. It's 1AM here in CA, so I'll head off now. Should I submit some kind of formal request mail on those two features I talked about?
[07:58]
MichaelDaumthats not required actually. in your place, I
'd just create a new extension package
HierarchicalAccessControlContrib ... something ... finding a good name isnt trivial either :)
[07:59]
TomAmbergOK, so I need to learn how to do that. Are you saying that these features would have to be implemented by me, and not have it be considered by (if such a thing exists) "central Foswiki engineering"? [08:01]
MichaelDaumhttps://foswiki.org/Development/ExtensionDeveloperGuide [08:02]
TomAmbergWould the "inherited page access" feature be able to be implemented via a plug-in, considering that it overrides other access preferences placed in the page? [08:07]
MichaelDaumyes [08:08]
TomAmbergOK, thanks. I have reading to do... [08:10]
................... (idle for 1h33mn)
***ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o MichaelDaum
[09:43]
.............................................. (idle for 3h46mn)
ChanServ sets mode: +o Lynnwood [13:33]
.................. (idle for 1h27mn)
ChanServ sets mode: +o cdot [15:00]
ChanServ sets mode: +o Lynnwood [15:08]
.......... (idle for 48mn)
ChanServ sets mode: +o Lynnwood [15:56]
ChanServ sets mode: +o cdot [16:01]
........... (idle for 54mn)
ChanServ sets mode: +o Lynnwood [16:55]
................. (idle for 1h24mn)
jmk0looking for a tool/process to put topics up for deletion, i.e. allow discussion/voting before topics are actually deleted. Suggestions? [18:19]
................... (idle for 1h32mn)
***geetar has left [19:51]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)