Menu
▾
▴
apc-aa-coders
|
From: Jakub A. <jak...@se...> - 2003-02-07 19:13:11
Attachments:
reader.html
|
Hello, I have partially finished changes needed for Reader Management. Especially there is some documentation in doc/reader.html, generated from docbook format doc/reader.xml. I am working further on this and I will send more info after other parts are done. This mail is meant as explanation to those who wonder what changes I am doing. I attach the file reader.html. Jakub |
|
From: Mitra <mi...@ea...> - 2003-02-08 02:00:37
|
At first glance this looks good Jakub, thanks. I think its a particularly good idea to use a slice for this, it gives us much more flexibility than defining a new separate data structure. One concern .... a common situation I have is where the user's have ability to edit some parts of a site, and controlled reader access to those and other parts of a site. For example this is the case where you have a the board of an organization wanting a shared space to post news articles. I'd like NOT to have to give these people two different sets of login ids, and manage them in two different places. Can we integrate the existing user management process for apc-aa/admin with this? So that one interface can be used to add users to groups for managing parts of other slices.. - Mitra At 8:12 PM +0100 7/2/03, Jakub Adamek wrote: >Hello, > >I have partially finished changes needed for Reader Management. >Especially there is some documentation in doc/reader.html, generated >from docbook format doc/reader.xml. I am working further on this and I >will send more info after other parts are done. This mail is meant as >explanation to those who wonder what changes I am doing. > >I attach the file reader.html. > >Jakub > >Attachment converted: Macintosh HD:reader.html (TEXT/MSIE) (00052D2A) -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Norbert B. <br...@ch...> - 2003-02-09 12:39:07
|
From: "Mitra" <mi...@ea...> > One concern .... a common situation I have is where the user's have=20 > ability to edit some parts of a site, and controlled reader access to=20 > those and other parts of a site. For example this is the case where=20 > you have a the board of an organization wanting a shared space to=20 > post news articles. I'd like NOT to have to give these people two=20 > different sets of login ids, and manage them in two different places.=20 > Can we integrate the existing user management process for=20 > apc-aa/admin with this? So that one interface can be used to add=20 > users to groups for managing parts of other slices.. So why not to put all user (not only reader) related information into = the slice? And I would like to suggest one more change if you are going to do it: = User have no longer access to the anonymous editing when is the item = changed by administrator (ITEM_FLAG_ANONYMOUS_EDITABLE is reset through = admin interface). It would be good to have this as a option. In come = cases we want users to change thier data even after they were changed by = the adminstrator (e.g. directory of NGOs - sometime NGOs update data by = themseleves, sometimes it is done by our editors). Norbert Brazda br...@ch... tel: 0905-729359 ChangeNet - informacny servis o obcianskej spolocnosti Mlynske nivy 41, 821 09 Bratislava, Slovakia tel/fax: 02-55560026, eMail: in...@ch... http://www.changenet.sk SPAJAME LUDI, KTORI MENIA SVET |
|
From: Mitra <mi...@ea...> - 2003-02-10 02:08:46
|
Yes - that would be my prefered solution - to put all user information into the slice. Jakub - can you do this? - Mitra At 1:38 PM +0100 9/2/03, Norbert Brazda wrote: >From: "Mitra" <mi...@ea...> >> One concern .... a common situation I have is where the user's have >> ability to edit some parts of a site, and controlled reader access to >> those and other parts of a site. For example this is the case where >> you have a the board of an organization wanting a shared space to >> post news articles. I'd like NOT to have to give these people two >> different sets of login ids, and manage them in two different places. >> Can we integrate the existing user management process for >> apc-aa/admin with this? So that one interface can be used to add >> users to groups for managing parts of other slices.. > >So why not to put all user (not only reader) related information >into the slice? > >And I would like to suggest one more change if you are going to do >it: User have no longer access to the anonymous editing when is the >item changed by administrator (ITEM_FLAG_ANONYMOUS_EDITABLE is reset >through admin interface). It would be good to have this as a option. >In come cases we want users to change thier data even after they >were changed by the adminstrator (e.g. directory of NGOs - sometime >NGOs update data by themseleves, sometimes it is done by our >editors). > > > > > >Norbert Brazda >br...@ch... >tel: 0905-729359 > >ChangeNet - informacny servis o obcianskej spolocnosti >Mlynske nivy 41, 821 09 Bratislava, Slovakia >tel/fax: 02-55560026, eMail: in...@ch... >http://www.changenet.sk > >SPAJAME LUDI, KTORI MENIA SVET > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com >_______________________________________________ >Apc-aa-coders mailing list >Apc...@li... >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Jakub A. <jak...@se...> - 2003-02-11 17:40:09
|
Norbert, Mitra and all, we were discussing in Econnect the unhappy situation of two user management systems and it does not seem possible to merge them. The AA permission system has many features which would be really hard to model by a slice. On the other hand the slice approach has such features which can't be modelled by the AA system. Our proposal is to add another Reader Management module, which will synchronize the AA permissions from the slice. It would be only one-way synchronization, i.e. users are added to AA permissions on addition to the slice and their password and email info changed in AA pemissions when changed in the slice. Please do think about it and write any ideas you have. It was a hard way to come to the decision to put the Readers into a slice, perhaps it would be possible to add AA permissions there also. But at the moment I do not much believe in it. Jakub > -----Original Message----- > From: apc...@li... > [mailto:apc...@li...] On Behalf > Of Norbert Brazda > Sent: Sunday, February 09, 2003 1:38 PM > To: apc...@so... > Subject: Re: [Apc-aa-coders] Reader Management Slice > > > From: "Mitra" <mi...@ea...> > > One concern .... a common situation I have is where the user's have > > ability to edit some parts of a site, and controlled reader > access to > > those and other parts of a site. For example this is the case where > > you have a the board of an organization wanting a shared space to > > post news articles. I'd like NOT to have to give these people two > > different sets of login ids, and manage them in two > different places. > > Can we integrate the existing user management process for > > apc-aa/admin with this? So that one interface can be used to add > > users to groups for managing parts of other slices.. > > So why not to put all user (not only reader) related > information into the slice? > > And I would like to suggest one more change if you are going > to do it: User have no longer access to the anonymous editing > when is the item changed by administrator > (ITEM_FLAG_ANONYMOUS_EDITABLE is reset through admin > interface). It would be good to have this as a option. In > come cases we want users to change thier data even after they > were changed by the adminstrator (e.g. directory of NGOs - > sometime NGOs update data by themseleves, sometimes it is > done by our editors). > > > > > > Norbert Brazda > br...@ch... > tel: 0905-729359 > > ChangeNet - informacny servis o obcianskej spolocnosti Mlynske nivy > 41, 821 09 Bratislava, Slovakia > tel/fax: 02-55560026, eMail: in...@ch... http://www.changenet.sk > > SPAJAME LUDI, KTORI MENIA SVET > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld > http://www.vasoftware.com > _______________________________________________ > Apc-aa-coders mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > |
|
From: Mitra <mi...@ea...> - 2003-02-13 03:14:14
|
I think if it is not possible to merge them, then what's needed is almost the opposite of what you suggest. I.e. there are typically more Readers than AA users, so when a user's password is changed in AA, then they should be automatically added to the Readers slice so that HTTP authentication can find it? Ram and I were doing something different, he had HTTP authentication working off the normal AA permissions - and I was adding a "READ" permission, my part never got finished, and Ram's wasn't using Groups yet, so probably what you have will be better - especially since non-superadmins can manage it. - Mitra At 6:39 PM +0100 11/2/03, Jakub Adamek wrote: >Norbert, Mitra and all, > >we were discussing in Econnect the unhappy situation of two user >management systems and it does not seem possible to merge them. The AA >permission system has many features which would be really hard to model >by a slice. On the other hand the slice approach has such features which >can't be modelled by the AA system. > >Our proposal is to add another Reader Management module, which will >synchronize the AA permissions from the slice. It would be only one-way >synchronization, i.e. users are added to AA permissions on addition to >the slice and their password and email info changed in AA pemissions >when changed in the slice. > >Please do think about it and write any ideas you have. It was a hard way >to come to the decision to put the Readers into a slice, perhaps it >would be possible to add AA permissions there also. But at the moment I >do not much believe in it. > >Jakub > >> -----Original Message----- >> From: apc...@li... >> [mailto:apc...@li...] On Behalf >> Of Norbert Brazda >> Sent: Sunday, February 09, 2003 1:38 PM >> To: apc...@so... >> Subject: Re: [Apc-aa-coders] Reader Management Slice >> >> >> From: "Mitra" <mi...@ea...> >> > One concern .... a common situation I have is where the user's have >> > ability to edit some parts of a site, and controlled reader >> access to >> > those and other parts of a site. For example this is the case where >> > you have a the board of an organization wanting a shared space to >> > post news articles. I'd like NOT to have to give these people two >> > different sets of login ids, and manage them in two >> different places. >> > Can we integrate the existing user management process for >> > apc-aa/admin with this? So that one interface can be used to add >> > users to groups for managing parts of other slices.. > > > > So why not to put all user (not only reader) related > > information into the slice? > > > > And I would like to suggest one more change if you are going > > to do it: User have no longer access to the anonymous editing >> when is the item changed by administrator >> (ITEM_FLAG_ANONYMOUS_EDITABLE is reset through admin >> interface). It would be good to have this as a option. In >> come cases we want users to change thier data even after they >> were changed by the adminstrator (e.g. directory of NGOs - >> sometime NGOs update data by themseleves, sometimes it is >> done by our editors). >> >> >> >> >> >> Norbert Brazda >> br...@ch... >> tel: 0905-729359 >> >> ChangeNet - informacny servis o obcianskej spolocnosti Mlynske nivy >> 41, 821 09 Bratislava, Slovakia >> tel/fax: 02-55560026, eMail: in...@ch... http://www.changenet.sk >> >> SPAJAME LUDI, KTORI MENIA SVET >> >> >> >> >> ------------------------------------------------------- >> This SF.NET email is sponsored by: >> SourceForge Enterprise Edition + IBM + LinuxWorld >> http://www.vasoftware.com >> _______________________________________________ >> Apc-aa-coders mailing list >> Apc...@li... >> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders >> > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >http://www.vasoftware.com >_______________________________________________ >Apc-aa-coders mailing list >Apc...@li... >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Jakub A. <jak...@se...> - 2003-02-14 18:44:55
|
I think that you are not right. The idea is to only allow to use the same username / password combination for the web (HTTP auth) and AA (sessions). No other settings are shared between Reader Management slice and AA permitions. Thus the only thing we need is when the user changes his or her password on Reader Personal Details page, so that the new password is propagated into AA. But I believe that it would be easy to do it the other way too if desired. Jakub > -----Original Message----- > From: apc...@li... > [mailto:apc...@li...] On Behalf Of Mitra > Sent: Thursday, February 13, 2003 4:08 AM > To: Jakub Adamek; apc...@so... > Subject: RE: [Apc-aa-coders] Reader Management Slice > > > I think if it is not possible to merge them, then what's needed is > almost the opposite of what you suggest. > > I.e. there are typically more Readers than AA users, so when a user's > password is changed in AA, then they should be automatically added to > the Readers slice so that HTTP authentication can find it? > > Ram and I were doing something different, he had HTTP authentication > working off the normal AA permissions - and I was adding a "READ" > permission, my part never got finished, and Ram's wasn't using Groups > yet, so probably what you have will be better - especially since > non-superadmins can manage it. > > - Mitra > > > At 6:39 PM +0100 11/2/03, Jakub Adamek wrote: > >Norbert, Mitra and all, > > > >we were discussing in Econnect the unhappy situation of two user > >management systems and it does not seem possible to merge > them. The AA > >permission system has many features which would be really > hard to model > >by a slice. On the other hand the slice approach has such features > >which can't be modelled by the AA system. > > > >Our proposal is to add another Reader Management module, which will > >synchronize the AA permissions from the slice. It would be > only one-way > >synchronization, i.e. users are added to AA permissions on > addition to > >the slice and their password and email info changed in AA pemissions > >when changed in the slice. > > > >Please do think about it and write any ideas you have. It was a hard > >way to come to the decision to put the Readers into a slice, > perhaps it > >would be possible to add AA permissions there also. But at > the moment I > >do not much believe in it. > > > >Jakub > > > >> -----Original Message----- > >> From: apc...@li... > >> [mailto:apc...@li...] On Behalf Of > >> Norbert Brazda > >> Sent: Sunday, February 09, 2003 1:38 PM > >> To: apc...@so... > >> Subject: Re: [Apc-aa-coders] Reader Management Slice > >> > >> > >> From: "Mitra" <mi...@ea...> > >> > One concern .... a common situation I have is where the user's > >> have > ability to edit some parts of a site, and > controlled reader > >> access to > those and other parts of a site. For example > this is the > >> case where > you have a the board of an organization wanting a > >> shared space to > post news articles. I'd like NOT to > have to give > >> these people two > different sets of login ids, and > manage them in > >> two different places. > >> > Can we integrate the existing user management process for > >> > apc-aa/admin with this? So that one interface can be > used to add > >> > users to groups for managing parts of other slices.. > > > > > > So why not to put all user (not only reader) related > > > information into the slice? > > > > > > And I would like to suggest one more change if you are > going > to > > do it: User have no longer access to the anonymous editing > >> when is the item changed by administrator > >> (ITEM_FLAG_ANONYMOUS_EDITABLE is reset through admin > interface). It > >> would be good to have this as a option. In come cases we > want users > >> to change thier data even after they were changed by the > >> adminstrator (e.g. directory of NGOs - sometime NGOs > update data by > >> themseleves, sometimes it is done by our editors). > >> > >> > >> > >> > >> > >> Norbert Brazda > >> br...@ch... > >> tel: 0905-729359 > >> > >> ChangeNet - informacny servis o obcianskej spolocnosti > Mlynske nivy > >> 41, 821 09 Bratislava, Slovakia > >> tel/fax: 02-55560026, eMail: in...@ch... > >> http://www.changenet.sk > >> > >> SPAJAME LUDI, KTORI MENIA SVET > >> > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.NET email is sponsored by: > >> SourceForge Enterprise Edition + IBM + LinuxWorld > >> http://www.vasoftware.com > >> _______________________________________________ > >> Apc-aa-coders mailing list Apc...@li... > >> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > >> > > > > > > > >------------------------------------------------------- > >This SF.NET email is sponsored by: > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > >http://www.vasoftware.com > >_______________________________________________ > >Apc-aa-coders mailing list > >Apc...@li... > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > > -- > Mitra Technology Consulting - www.mitra.biz - > mi...@mi... 02-6684-8096 or 0414-648-0722 > > Life is a Mystery to be Lived, not a Problem to be Solved > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Apc-aa-coders mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > |
Thanks for helping keep SourceForge clean.
X