1 Jul 11:10
1 Jul 14:19
Aegir v2 development
Dear all, I hereby announce that Leeds Health Informatics Service (a part of the UK NHS) has decided to help fund the development of a new version of Aegir. The version will be built as a custom Midcom style and a set of new midcom components. All components will be licensed under GPL or LGPL. The first part of this project will be to provide a road map for components and for starting discussions on how the interface should look. This will be started on monday. I think that is all for now, expect more mails as the project moves forward and do not hessitate to ask questions or provide inputTarjei
4 Jul 09:34
ACL proposals for MidCOM 2.6 / future Midgard
Hi, as most of you will know by now, MidCOM got a new, full-fledged ACL system as outlined in mRFC 15. The current implementation is based on the new MidCOM Database Abstraction Layer (MidCOM DBA) and thus works only on MgdSchema installations. My goal has been to provide an ACL interface for all components as transparently as possible. Since MgdSchema does not yet provide access control whatsoever, I have to make a proposal in this respect: I do not have the knowledge or the time to work such things in the Midgard Core (where it undoubtly belongs), but what I can do is working on it on the MidCOM level, where I already have a powerful framework at my disposal. So what I want to do is implementing an ACL implementation on the MidCOM core level which is geared for DBA only at this point. This implementation can then be transferred to the core step by step when Piotras gets around to it and the more immediate problems are fixed. For this I will introduce a number of permissions in the "midgard" permission space, which will be checked on corresponding core DBA operations (create, delete ...). Since MidCOM 2.6 already *requires* usage of DBA for all MgdSchema based objects (they must not be used directly), MidCOM has full control over this part of the framework. Legacy applications still working with the old objects are not a matter here at this point, as they are captured by the old Midgard core. As soon as a compatibility layer (most probably built on MidCOM) is available, this does not matter anymore anyway).(Continue reading)
4 Jul 13:14
Re: ACL proposals for MidCOM 2.6 / future Midgard
Hi again, --Torben Nehmer wrote on 2005-07-04 09:34: > midgard:parameters > Allos the manipulation of parameters according to the permissions of the parent > object. This means that you still need write access to the object to write > parameters, or delete access to the object to delete parameters, etc. Use this > permission to selectivly prohibit operations on parameters on an object the user > normally has access to. This is granted by default. > > midgard:attachments > Analog to midgard.parameters, just for attachments. This is granted by default. A question here: Does it conecptually really make sense to link parameter/attachment deletion to the object deletion permission? Or is it more sensible to treat deletions of these sub objects as updates of the main object? Or, as a third alternative, should we add explicit privileges to contol deletion of parameters/attachments? Live long and Prosper! Torben Nehmer -- Torben Nehmer, Guenzburg, Bavaria, Germany(Continue reading)
4 Jul 13:33
Re: Aegir v2 development
On Jul 1, 2005, at 15:19, Tarjei Huse wrote: > Dear all, Greetings! > I hereby announce that Leeds Health Informatics Service (a part of > the UK NHS) has decided to help fund the development of a new > version of Aegir. Great! Modernizing Aegir has definitely been long due.. > The first part of this project will be to provide a road map for > components and for starting discussions on how the interface should > look. This will be started on monday. I suggest taking a look at the OpenPSA 2.x preview: http://bergie.iki.fi/midcom-permalink-612a8f963c58a9bd0304e33c7b59df88 OpenPSA 2.x is also built on top of MidCOM, and the UI utilizes XHTML, CSS and AJAX (where it makes sense). I suggest Aegir and OpenPSA could try to follow somewhat similar design patterns. Some components might be shared as well, like the OpenPSA Contacts user/group manager. Also, the testing approach you've been talking about would be very useful not only for Aegir, but also for MidCOM core and OpenPSA.(Continue reading)
4 Jul 17:45
RE: manual pages
I should be able to help out as long as we are not on to tight of a schedule. Let me know the details... --- Adam Douglas Webmaster Venmar CES Inc. Ph: (306) 242-3663 Fax: (306) 242-3484 E-mail: adouglas@... <mailto:adouglas@...> Web: http://www.venmarces.com/ -----Original Message----- From: Piotras [mailto:pp@...] Sent: Friday, July 01, 2005 3:11 AM To: dev@... Subject: [midgard-dev] manual pages Hi all! I am looking for volunteer(s) who would like to write midgard manual pages. midgard-config and all midgard-*** scripts repligard datagard Anyone?
6 Jul 10:20
Re: ACL proposals for MidCOM 2.6 / future Midgard
Hi, My 2 cents. Torben Nehmer wrote: > Does it conecptually really make sense to link parameter/attachment deletion to > the object deletion permission? > > Or is it more sensible to treat deletions of these sub objects as updates of the > main object? > > Or, as a third alternative, should we add explicit privileges to contol deletion > of parameters/attachments? I'd vote for option 2, i.e. to treat parameter/attachment operations as updates to the main object. It's a simple and clear model; parameters and attachments are equivalent to the normal properties and content of an object. Specifically, I see no use case where a user would have more specific permissions and _not_ be allowed to update the main object. It is conceivable however, that a user is given the rights to update an object (along with it's attachments etc.) but not the right to delete it. BR, Jukka Zitting
6 Jul 10:27
Re: Aegir v2 development
Hi, > > The first part of this project will be to provide a road map for > > components and for starting discussions on how the interface should > > look. This will be started on monday. > > I suggest taking a look at the OpenPSA 2.x preview: > http://bergie.iki.fi/midcom-permalink-612a8f963c58a9bd0304e33c7b59df88 I did, it's comming along very nice :) > OpenPSA 2.x is also built on top of MidCOM, and the UI utilizes > XHTML, CSS and AJAX (where it > makes sense). Yes, I'm thinking of using AJAX in the navigationmenu. > I suggest Aegir and OpenPSA could try to follow somewhat similar > design patterns. Some components > might be shared as well, like the OpenPSA Contacts user/group manager. Yes please :) > We have a lot of stuff to do with OpenPSA this summer, so I think it > will make sense to work quite closely > together in these two projects. +1 I'm looking forward to the cooperation :) Tarjei > > > Tarjei > > /Bergie(Continue reading)
6 Jul 10:39
Re: ACL proposals for MidCOM 2.6 / future Midgard
Jukka Zitting <jz@...> wrote: > > Or is it more sensible to treat deletions of these sub objects as updates of the > > main object? > > > > Or, as a third alternative, should we add explicit privileges to contol deletion > > of parameters/attachments? > > I'd vote for option 2, i.e. to treat parameter/attachment operations as > updates to the main object. It's a simple and clear model; parameters > and attachments are equivalent to the normal properties and content of > an object. Specifically, I see no use case where a user would have more > specific permissions and _not_ be allowed to update the main object. It > is conceivable however, that a user is given the rights to update an > object (along with it's attachments etc.) but not the right to delete it. We should delete parameters and attachments types from schema then. We should implement particular parameters and attachments management in core which *is not* part of an object but indeed *is*. Serving parameters as GObject properties is impossible anyway. And let's think about *real* examples: 1. MidCOM's objects uses the same ( I mean domain , name and value are the same ) parameters. 2. Aegir's gallery ( or similiar ) used attachments attached to topic to let them be "shareable" between articles. 3. There are plenty of apps which need to have the same image to be attached to different objects. Parameters itself are difficult ( if you think about porting to core ) midgard-php exception, but attachemnts should be real standalone objects which may be attached to any kind of object.(Continue reading)
6 Jul 10:47
Re: mRFC 0018: Adopting the UUID and URN standards
Hi, The UUID URN RFC was just published (see [1]), which means that mRFC 18 [2] is now ready for a vote. I moved the mRFC into the Proposal state and gave the first vote. Please cast your votes or comment if more clarifications are needed. I'd very much like this proposal to be accepted, and I have the funding (from the DBE project) to implement the proposed changes. The UUID mRFC lays the foundation for two more mRFCs (improved change history and versioning support in Midgard) that I'll be submitting in a short while. These are key issues for implementing the proper distributed and incremental replication needed for the OpenPSA DBE project. [1] ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt [2] http://www.midgard-project.org/community/development/mrfc/0018.html BR, Jukka Zitting
RSS Feed