You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This may be a use case where what subjects to display should be restricted depending on the user. One example is when you have old and new divisional sub-tree. You don't want regular users to be able to use the old sub-tree divisions but you want editors/admins to be able to add these items to a divisions.
Allowing MetaField::Subjecttop attribute to be a function is useful but it could have unintended side effects. A user that does not have access to some subjects for a field could unset these subjects if they are being used and not in the sub-tree they can see. Therefore, it is essential to set the workflow component to type Field::Subject
The text was updated successfully, but these errors were encountered:
Like for #389 this can be done in the workflow XML. It is probably best this is reverted so as not to leave two methods to do the same thing which may lead to confusion.
This may be a use case where what subjects to display should be restricted depending on the user. One example is when you have old and new divisional sub-tree. You don't want regular users to be able to use the old sub-tree divisions but you want editors/admins to be able to add these items to a divisions.
Allowing
MetaField::Subject
top
attribute to be a function is useful but it could have unintended side effects. A user that does not have access to some subjects for a field could unset these subjects if they are being used and not in the sub-tree they can see. Therefore, it is essential to set the workflow component to typeField::Subject
The text was updated successfully, but these errors were encountered: