david at kineticode
Nov 19, 2008, 9:24 PM
Post #2 of 10
(2005 views)
Permalink
|
On Nov 19, 2008, at 6:16 PM, Beaudet, David wrote:
> I've got a fairly hacked version of Bric 10.2 , so I don't know if
> this
> is something I introduced or not to my own system, but if a user
> doesn't
> have access to a start desk, but does have access to subsequent desks
> and access to recall a particular story, shouldn't the story get
> placed
> on the first desk they have edit permissions on?
Maybe. But it's not designed that way.
> Right now, the story
> goes on the start desk, but then the user cannot edit it. This could
> very well be a result of some hacks I've done to enforce desk
> permissions which I describe as follows, and now that I read it, is
> probably the case.
Maybe. But assets are alway put on the start desk when users create or
recall them.
> Assuming I eventually commit the change and
> associated config directive, the question is still relevant though.
> If
> a user has access to desks further up in a workflow, their "start
> desk"
> might very well be different from somebody else's in that we don't
> want
> to recall a story to a desk that has insufficient permissions for the
> person recalling the story to edit the story.
Yes, that's right. The current design, where all things go on the
start desk when they enter a workflow, predates the addition of the
RECALL permission. So it may very well need re-evaluating. As it is,
however, one cannot recall a story into a workflow unless one has
RECALL permission to the start desk. I mean, I think you can give a
user RECALL permission to a category of documents, for example, but
they can't recall any of those documents into a workflow where they
don't have at least READ access to the start desk.
> # Workflow desk permission enforcement. By default, a
> non-administrative user's
>
> # permissions on an asset are determined by taking the highest
> permission available on
>
> # any permissionable aspect of the asset (category, element type,
> etc.),
>
> # including permissions on the assets current desk within a
> workflow. A
> side
>
> # effect of this highly trusting and collaborative approach is that a
> user can
>
> # search for and edit an asset with the "Find" feature even though the
> user has
>
> # no permission to the asset's current desk.
Say what? You can't edit a document if you can't pull it into workflow.
> Some customers might prefer
> to enforce
>
> # the workflow permissions separately from asset permissions, thereby
> taking the
>
> # LESSER of the highest permission allowed by the asset and the
> highest
>
> # permission allowed by the desk in the asset's current workflow.
> This
> provides an
>
> # effective way to 'protect' an asset once it reaches a certain desk.
>
> # To enable this feature, set this directive to "Yes", "On", or "1".
That sounds like a cute hack, but stands to make permissions even more
confusing than they already are. I'm not sure if that's a good thing…
Best,
David
|
