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_assi...
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
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_assi...
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
