phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [phpGroupWare-developers] linking items across applications


From: Sigurd Nes
Subject: Re: [phpGroupWare-developers] linking items across applications
Date: Sun, 28 Oct 2007 21:54:26 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

Maat wrote:
> Sigurd Nes a écrit :
>> Maat wrote:
>>
>>> perhaps we need also :
>>>
>>> -- something to make link inactive without deleting it
>>>   
>> It could be Inactive when end_date expires.
> 
> 
> ok then you cannot disable a link during its active period check
> something the re-active it 2 days later.
> perhaps this case will not appear :/
> 
> 
>>> -- something to define the "type" of the link
>>>
>>>   
>> Ok - that is possibel - can you explain what you mean by "type" - and
>> how it should be used?
> 
> yeah.
> 
> example : for a given type of task ( in tts, in task manager) you'll
> have to link to documents you need to change but also to documents like
> instructions or guides for the said task.
> 
> => you'll have to make a difference : offer upload forms somewhere in
> the page for the documents you need to change
> 
> => show in a "help" zone the documents linked "for information"

Intuitively - this sounds to me like information that belongs to the
target - and should be derived from a method defined in a hook.

(btw: "target" might be a better word than "destination")
>> Here is my (revised) proposal for schema:
>> 'phpgw_interlink' => array(
>>     'fd' => array(
>>         'interlink_id' => array('type' => 'int', 'precision' => 4, nullable 
>> => false),
>>         'origin_app' => array('type' => 'varchar','precision' => 
>> '25','nullable' => false),
>>         'origin_location' => array('type' => 'varchar','precision' => 
>> '12','nullable' => false),
>>         'origin_id' => array('type' => 'int','precision' => '4','nullable' 
>> => false),
>>         'destination_app' => array('type' => 'varchar','precision' => 
>> '25','nullable' => false),
>>         'destination_location' => array('type' => 'varchar','precision' => 
>> '12','nullable' => false),
>>         'destination_id' => array('type' => 'int','precision' => 
>> '4','nullable' => false),
>>         'is_private' => array('type' => 'int', 'precision' => '2','nullable' 
>> => false),
>>         'account_id' => array('type' => 'int','precision' => '4','nullable' 
>> => false,
>>         'entry_date' => array('type' => 'int','precision' => '4','nullable' 
>> => false),
>>         'start_date' => array('type' => 'int','precision' => '4','nullable' 
>> => true),
>>         'end_date' => array('type' => 'int','precision' => '4','nullable' => 
>> true),
>>     ),
>>     'pk' => array('interlink_id'),
>>     'fk' => array(),
>>     'ix' => array(),
>>     'uc' => 
>> array('origin_app','origin_location','origin_id','destination_app','destination_location','destination_id')
>> ),
>>
>>   
> 
> ok but the "location" thing is not really clear for me

Location is a logical submodule within an application - which can be
organized as a hierarchy.
Rights are inherited down the location-hierarchy.

There are two different aspects of the ACL (and ACL2):

   1. Give groups/users rights per locations  within applications.
   2. Grant other users rights related to ones (the grantor) records.
These rights can be defined with a group as the grantor.

Granting permission

The locations "run"  and 'changepassword' are not listed at locations,
and are not subject to inheritance - because these locations are handled
in the user-setup.

Example: Locations that are to be part of inheritance are named as:

  .
  .location1
  .location1.sublocation1
  .location1.sublocation2
  .location2
  .location2.sublocation1
  .location2.sublocation2

Locations must be allowed to give grant - this is set in the
allow_grant-column in the phpgw_acl_location-table. As an example - only
the location '.user' is allowed to give grant in the app 'hrm'.

Global categories for the application will be listed for both permission
and granting as:

  $locations[$i]['id']    = 'C' . $cat['id'];
  $locations[$i]['descr']    = $cat['name'];

If you want - you can use each document in ged as a location - and apply
ACL2 to it.
example within the app ged: .documents.<catalog>.<doc_id>

The acl-class checks the groups-rights first - and then re-check for
user-rights

One can give a group some rights - and then mask - or give additional
rights for specified users.

In order to check if a user is allowed to add a record in
'.location1.sublocation1' at 'some_application' - one has to check for:

    $GLOBALS['phpgw']->acl->check('.location1.sublocation1',
PHPGW_ACL_ADD,'some_application')


if the applicationname is not given - currentapp will be assumed.

check for grants:

in so-class:

$this->grants=$GLOBALS['phpgw']->acl->get_grants('some_application','.location1.sublocation1');
      .
      .
      .
  while ($this->db->next_record())
  {
      $ngrants = $this->grants[$this->db->f('account_id')];
      $account_info[] = array
      (
          'value'        => $this->db->f('value'),
          'grants'    => $ngrants
      );
  }

>> I think the link should be unique (could possible conflict if different user 
>> should be able to make the same relation - hidden from each other).
>> It also holds the validation data requested by maat, making link inactive 
>> without deleting it.
>> I prefer to use origin and destination over app1 and app2.
>> As for origin/destination_location - the class entity in the app property 
>> handles a wide variety of items
>> (could be several hundreds when a set of IFC-entities is loaded) - so 
>> classnames would be useless.
>>
>> Do you really think it is necessary with a full blown acl controll of the 
>> relation between items - I think the acl control of the items itself should 
>> suffice.
>>
>>   
> dunno but you'll have link from object you are entitled to play with to
> objects you aren't
> 
> what if a change on the object triggers actions on the linked objects ?
> 
> are the triggers considered to be launched with admin rights ?
> 
> if not, the denial on the actions are likely to produce data inconsistencies
> 

That can be achieved with custom-drop-in-functions - as implemented in
property. Or it would be possible to check for any links from the item
you are touching - and check if there is any hooks at the target end -
and perform what ever defined.

Regards

Sigurd








reply via email to

[Prev in Thread] Current Thread [Next in Thread]