nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Aspect & properties permissions

fguillaume

Hello,

I've read that permissions cannot be set at a properties level. I have a requirement where only a subset of any document's properties can be read by the members of Group A, while members of Group B have access to all the properties of the same document.

Is it possible to group the properties that can be read only by Group B on a aspect, and give the read/write permissions for this aspect only to the members of Group B? By doing so, members of Group A would never been allowed neither to read nor to write these "special" properties.

If this is possible, can anyone indicate me a way to achieve this?

Many thanks,

Guillaume

Find more posts tagged with

Comments

sacco

I've read that permissions cannot be set at a properties level.

This is correct: such a possibility is not currently exposed in the Alfresco data model.

Is it possible to group the properties that can be read only by Group B on a aspect, and give the read/write permissions for this aspect only to the members of Group B? By doing so, members of Group A would never been allowed neither to read nor to write these "special" properties.

I don't believe that it is straightforward to do this unless your requirements are rather simple
… edited: see post below for further discussion

If this is possible, can anyone indicate me a way to achieve this?

A better approach, I think, would be to separate the properties concerned into another node which can then be
related to the main node either as a child (so the main node becomes a compound structure) , or by using
associations.

fguillaume

Hello,

In this case, what would this new node be? A type or an aspect that would contain only the properties that can be shown to Group B?

Thank you for your help,

Guillaume

sacco

Yes, you would need to define a type for the new node to contain the properties
intended to be accessible only by Group B. These nodes can now have their
access permissions managed independently of the main node: you will probably
want to automate some of this using JavaScript (I think you ought to be able
to do most of what you need by working at this level, rather than delving into
the Java source).

To be strictly accurate, I've been slightly misleading here: it is
actually possible to achieve what you want as you described by defining a new
aspect and controlling access to it, e.g:

http://wiki.alfresco.com/wiki/Security_and_Authentication#How_to_add_your_own_type_or_aspect.2C_assign_permissions_for_it.2C_configure_it_and_secure_a_service_that_uses_it_....

However, this is a lot more complicated, and may require you to provide
low-level infrastructure to support it (depending upon exactly what you're
trying to achieve). If, as I assume from your question,
you're aiming to leverage the built-in Alfresco security model and work
mainly at the level of configuration then the approach using a separate
auxiliary node is probably more suitable. If, on the other hand, the precise
working of this feature is central to your application, and you're happy to
wade into the Java source code without a huge amount of detailed documentation
then you might try to define a secure aspect as you originally suggested.

To sum up, using an aspect may be the "correct" way to solve certain problems
and may slightly simplify other aspects of you application. However, I have
sometimes found it difficult to achieve precisely what I required in this way,
even when I've been fairly sure it was possible. The documentation is sparse,
and the fact that the functionality is effectively hidden (so far) means that
it could be subject to change.
The approach with a separate note is clumsier and may require some extra
plumbing (although this can be done at a higher level), but it is easier to
see exactly what is going on, and it can be realised mainly using already
familiar functionality. You need to decide what will work best for you.

A final issue to consider is the intended lifetime of your application and the
resources available to support and maintain it: by working at a higher level,
the approach using a separate node would be more likely to survive upgrades
to the Alfresco system than custom code (at least until more of this functionality
is exposed at a higher level).

I hope all this waffle helps rather than simply adding confusion