[Core] Master / slave enhancements

[admin]

---

0016805: [Core] Master / slave verfijningen
 http://mantis.kennisnet.nl/view.php?id=16805

Momenteel kan elke applicatie master/slave records toewijzen aan elke willekeurige andere applicatie. Ik zie een aantal mogelijke manieren om hier wat beperkingen in te gaan stellen;

1. We gaan per ega een flag instellen die de ega wel of niet toestaat om deze master/slaves aan te maken. NIBG moet deze optie natuurlijk krijgen, en leraar24 niet (om maar een voorbeeld te noemen)

2. We gaan in de beheer interface een mogelijkheid aanbieden om ega's aan elkaar te koppelen. dwz standaard heeft een ega geen mogelijkheid om ze aan te maken, tenzij bij de ega's die ingesteld zijn in de beheer interface.

3. Er komt een soort inbox mechanisme met goedkeur mogelijkheid, voor ega en/of op asset niveau.

prio high omdat dit toch wel wat ongewenst gedrag kan opleveren bij meerdere gebruikers van VP-Core

[MC-arjen]

review request

[robert]

Op elke EGA kan nu een ja/nee worden ingesteld dat er van die EGA een master/slave setting mag worden gezet.

[Michiel.Schok]

Mixed feelings.

First I'm looking for confirmation that it is the setting under 'Client Applications', 'Master / Slave' settings in the management portal.

If so, that setting is already available on 1.6.4, I observe no change to 1.7.0 in the setting.

Second, it's an all or nothing switch to 'accept' slave records. As applications like 'Edit', 'Teleblik' and 'SURFmedia' already want to accept slave records from 'NIBG' this setting is set to 'yes' for them.
Automatically *all* other EGA's are able to create slave records in those applications. I don't think that was the idea behind the original posting.

I've tested this issue, and indeed, if an application (9) has it's master/slave settings disabled, when trying to *create* an ACL on a master using [post] /mediafile/{id}/acl?user_id=owner&aut_app=9 , an error 1403 (Master/slave relations for 9 disabled) is given. Enabling the setting and retrying the call results in 601-success.

Possible caveat: When switching the switch to 'off', any slave relations created previously are still active. They have to be removed by the owner of the asset (the master, that is).

I've tested this issue, but won't close it because concerns given above.

[Frans]

What happend to the request / accept mechanism in the case the switch has been set to on. I can't accept the solution although it is already on the 1.6.4. release in production.

Feedback / discussion needed.

[MC-arjen]

The current implementation was the solution with the least possible impact (in development hours) and still be able to secure applications. In retrospect it would have been better to turn the solution around (that is: to give certain applicaions the right to share files, instead of to allow application to receive files.)

I agree we have to work out a better solution with a request/accept mechanism.

We need to choose a strategy (The impact in development effort rises):

• change the current solution in a "right to share" setting,
• or leave the current setting and add a "right to share" setting,
• we could change the admin interface to be able to specify per ega what ega's kan share files to them,
• we could do the last option with a set of rest calls, so no administrator is needed.
• we can implement an inbox of asset-shares to which an ega has to approve the individual assets.

status: feedback required.

[Frans]

We opt for option 3: "we could change the admin interface to be able to specify per ega what ega's kan share files to them".

Works for us with the least of impact.

[Frans]

Moved to MediaMosa 2.1

[Michiel.Schok]

Textual update required, changes mentioned in bold.
Functionality is OK.

On the 'Client application edit screen' (eg.  http://beheer.acceptatie.vpcore.snkn.nl/node/23/edit)

it says under 'Master/Slave? settings'

"Control how other clientapplications can access this application"

I think that should read:
"Control which other client applications can slave assets to this application"

Beneath the listbox it read:
"Select other client applications that are allowed to master/slave your assets and mediafiles. Use SHIFT or CTRL to select more than one application. If no applications are selected, then no application can master/slave your assets/mediafiles (default)."

That should be:
"Select other client applications that are allowed to master/slave their assets and mediafiles to this application. Use Use SHIFT or CTRL to select more than one application. If no applications are selected, then no application can master/slave their assets/mediafiles to this application (default). Existing master/slave rules will continue to function."

[MC-arjen]

Commited to 2.1.2, Thx for the patch!

[Michiel.Schok]

Great text, perfect copy/paste ;-)