Default Content Type preference determination

(Douglas (@finnatic at @waikato)) #1

We have a user whose access to a site used for content creation has the preference unset, so that the group says it will be using the global default.  The global default content type is set to WYSIWYG.

 

The user is a member of another group (used to provide edit/admin access to a different site) which has the preference set to raw HTML.

 

Why does Matrix not use the preferences for the group being used to provide and restrict access?  Is there anyway I can set that or override the second group's preference?

 

 

(Nic Hubbard) #2

I think that it goes with the highest level of permissions. So, that group that has admin access takes precedence.

(Douglas (@finnatic at @waikato)) #3

That may explain partly what we're seeing.  The raw HTML preference is on a group which has admin access to the second site - site B.

 

However, that preference is turning up in Edit+ for the user who has edit access to site A through another group, and where the admin group for site B does not have any access.

(Douglas (@finnatic at @waikato)) #4

Bump.

 

Any further comments or ideas?  I'm left thinking the only solution here is to tell the admin group for site B that we need to change their group preferences due to issues the user is having with site A.

 

I've looked through the trigger actions and as far as I could tell there's no action to set or change the content type on an asset using a trigger?

(Douglas (@finnatic at @waikato)) #5

Final bump.  This is something where having an order in which group preferences are applied (e.g. asset map order) would be very useful.

(Bart Banda) #6

I think it's based on the link value of the group that the user is linked to. So later links into groups will always take precedence over older links, if that makes sense? Is that what you are seeing? 

(Luke Wright) #7

Final bump.  This is something where having an order in which group preferences are applied (e.g. asset map order) would be very useful.

 

From what I am grasping of the code, the preferences code in general prefers groups that are deeper in the tree. It uses getParents() to get the list of groups, and the default order appears to be that of decreasing tree depth (doesn't appear to specify what happens to multiple-links).

 

For instance, if you have a structure of two parent groups /A/U and /B/C/D/U where U is your user and the others are user groups, it will apply preferences at C before that at A, despite the latter being closer to U.

 

However--

 

There is one last wrinkle to this, and that is: each asset type's preferences are allowed to determine how their preferences are merged. For the Default Content Type preference, it will always prefer content types other than WYSIWYG when merging preferences from two applicable groups. So in the case you're offering, there is currently no way to override a preference for a non-WYSIWYG content type with a WYSIWYG Content Type selection, even if it would otherwise have priority.

 

I'm not sure why it was written that way, except for thinking that WYSIWYG [being at one point the only "free" content type, back in the Matrix 3.x days] would always want to be overridden with something, and didn't make sense for it TO override something else (maybe because they were considered equal priority). This assumption may no longer be valid (and I'm not sure it's even documented to work that way) so it may become part of our Squizmap to-do list if there's no reason why it should be that way. No guarantees though - only that I'll raise it.

 

Thanks for your question(s) Douglas; sorry if the current answer disappoints you.

(Douglas (@finnatic at @waikato)) #8

Bart, Luke - thanks for your suggestions and research.

 

The squizmap idea resulting from my post regarding updating content type settings in bulk (http://forums.squizsuite.net/index.php?showtopic=13276) suggests a possible future solution to the underlying problem here (the content type not being WYSIWYG at creation).  

 

In testing, I can't be sure really what is happening - our structure has Groups under the Users Folder and then LDAP users linked in under the various groups, such that the affected user is nested something like:

* Users folder/Org unit folder/Org unit subfolder/Org unit group/User - group used to control access to the site in the OP question

* Users folder/Org unit folder/Org unit group/User - group setting the raw HTML preference.

 

The link ids for the raw html are older (and therefore smaller numbers)... 

 

What I'm trying is a separate preferences group which has worked for me in testing so that I can remove the preference from the Org Unit group.  We'll see how it works.