Re: [yaco-liaison-tool] The liaison tool: Status Update

["Emilio A. Sánchez" <[e-mail]>]

El 07/04/11 11:19, Patrik Fältström escribió:
> On 7 apr 2011, at 11.08, Emilio A. Sánchez wrote:
>
>>> The important thing is to be able to update the liaisons. And we can trust our (IETF) liaisons, so to get fine-grained access rights is not so important. The ability to get things right in the database is. Having bad data in the database -- as now -- is not working in the long(er) run.
>>
>>    I suppose, as I said in my previous mail, that the problem is who can 'take care' (mark as done) a liaison. Right now this action can be done by anyone whose email is listed in the liaison. But probably I should add the people that can edit the liaison to the ones that can 'take care' of it.
>
> That imply that someone from ITU-T that is the receiver of a liaison can log in an edit an outgoing liaison that they receive... "interesting feature"...
>
> You have an access right already today when one add a liaison, right? That access algorithm say whether you as a user can add certain data in the to/from fields.

    No, no, no. He can use the button "Take care of" (the one that 
appears in the detail of a liaison next to 'No actions taken') cause he 
(as a receiver) can now if the liaison has been taken care.

    People who can edit a liaison are:

    * The secretariat (always)
    * A Liaison Manager with these conditions:
       * For outgoing liaisons: If the liaison was sent to its SDO
       * For incoming liaisons: If the liaison was sent from its SDO

> 1. An external party, for example someone from ITU SG2, should only be able to add a liaison that is incoming to IETF from SG2, but with various receivers on the IETF side.
>
> 2. An internal party, for example liaison to ITU-T SG2, should only be able to add liaisons to or from IETF and that external party.
>
> 3. An internal party that has power gloves, like the liaison to ITU-T should be like (2) but for more SG's than one
>
> 4. Secretariat should be able to access everything
>
> Easiest way of course for 1, 2 and 3 is to have the ability for each user to map that to one relationship, and whether the access is incoming or outgoing. For example:
>
> A. A user have access to some external groups (zero or more).
>
> B. If the user is _incoming_ then the user can only add incoming liaisons.
>
> C. If the user is _outgoing_ then the user can add incoming, outgoing liaisons AND edit the liaisons.
>
> But once again, I am not so worried about giving people "too much access" to start with, because we have had problems for years with having not enough access in the tool.
>
> So lets start with what you now have created! Sounds fine!
>
>     Patrik
>