Context Specific Templates

This forum post is in regards to a feature request I posted on the modx bug tracker: http://tracker.modx.com/issues/6941

I posted out a little call for help on Twitter, but being limited to 140 chars makes explanation of a problem somewhat challenging. So I decided it would be best to make a forum post where I can better explain the situation by offering a hypothetical (and dumbed down) example in order to either get some clarification on what I seem to be missing, or better explain my feature request.

Sooo... for the sake of example we have a young entrepreneur named "John". John has both a dog grooming business (Bath Time Inc.) as well as a Landscaping Business (Johns Lawns Inc.).

John being the intelligent business man he is, hires me to create two separate websites for his two businesses (bathtimeinc.com & johnslawns.com). He notes that it is very important for him to have a unified content management system where he can edit each site individually without having to log in to two entirely separate managers.

"Great!"...I suggest using MODx, since multiple contexts should be a perfect solution! So I develop Johns sites in a single Modx install...and the setup looks as such.

jli (Context)
- Home (Resource)
- Contact (Resource)

Lawns (Category)
- LawnHomeTpl (Template)
- LawnGenericTpl (Template)
____________________________

bti (Context)
- Home (Resource)
- Contact (Resource)

Bathtime (Category)
- BtHomeTpl (Template)
- BtGenericTpl (Template)
____________________________

This is great! John is thrilled! Now with only one login and password, John can go in and make adjustments to both of his individual sites!

All is well on the front...but wait... John decides that it's time to expand the services of Bath Time Inc. to include Dog Walking. So..he logs in to his modx install and right clicks "bti" (context) and chooses "Create Resource Here". Wow! "It's So Easy!" John exclaims as he enters the word "Services" into the pagetitle field. John then moves down and fills in all of the content he wants quickly and easily thanks to TinyMce. Now it's time to choose a template... John sees the four templates (mentioned above) available to him and (mistakenly) selects "LawnGenericTpl" as opposed to "BtGenericTpl" that he probably intended to. He saves his new resource and excitedly heads to preview the fine work he just did. Woooahh.. John's new service page has the logo and theme of his lawn service business..but yet his content says that he offers Dog Walking... He looks at the url to make sure he didn't accidentally edit the wrong site..but it says "bathtimeinc.com" just like it should. How in the world is this possible he wonders!? John then gives me a call wondering why his new website that he spent so much money on is so easy to mess up...

Well... You and I both know that John just selected the wrong template.. but you and I also both know that this is a pretty serious UX issue. John shouldn't be able to see his Lawn site templates as an option when editing his Dog Grooming site (Bathtimeinc.com) pages.

In a perfect world (in this situation) John would have only had two template options available (BtHomeTpl & BtGenericTpl)...but in Modx world.. It appears there is no way for John to have the excellent user experience we'd like to give him.

So in order to fix this issue... I setup Johns permissions as follows:
____________________________________
JOHNS PERMISSIONS (SCENARIO 1):
Editor (Usergroup) | Super User (Role)

Context Access

Context | Min Role | Policy

- mgr | Super User | Content Editor
- jli | Super User | Content Editor
- bti | Super User | Content Editor

Element Category Access

Category | Min Role | Policy | Context

- Lawns | Super User | Element | jli
- Bathtime | Super User | Element | bti
____________________________________
Well...that makes sense.. John has access to the "Lawns" category..but only within the "jli" context. Likewise, John only has access to the Bathtime category within the "bti" context. Sounds like we have a winner right? Unfortunately not... When John is adding/editing resources, John is in the "mgr" context.. So if John tries to add an "About Us" page...he'll come to find that rather than 4 templates available...he'll have NO templates available.

That should be an easy fix... I'll just give him access in the mgr context like in scenario 2 below..
____________________________________
JOHNS PERMISSIONS (SCENARIO 2):
Editor (Usergroup) | Super User (Role)

Context Access
Context | Min Role | Policy

- mgr | Super User | Content Editor
- jli | Super User | Content Editor
- bti | Super User | Content Editor

Element Category Access
Category | Min Role | Policy | Context

- Lawns | Super User | Element | mgr
- Bathtime | Super User | Element | mgr
____________________________________

Woohoo.. John can see the templates again...but wait...we're back to stage 1... John can see ALL of the templates again..no matter what context he is adding a resource to.

Now when I initially posted this "Feature Request" I had no idea the amount of explanation that would be involved... It's one of those things that makes perfect sense since you are the one doing it, but to others it could be extremely confusing. Prior to posting the Feature request I explained the situation to a couple of MODx Pros, that I respect greatly. In each situation both immediately jumped to the conclusion that of course it was possible with ACLs...but the more they thought about it..the more they realized that wasn't the case.

So, the scenarios above are what I have tried... what am I missing?

@BobRay: Your suggestion on twitter was to associate a category with a resource group. However, under the Resource Group ACL tab, I do not see "Category" anywhere... and likewise on the Element Category ACL tab, I do not see "Resource Group" available anywhere to make any associations. As far as I can tell, it appears you can only associate either of these with a context. I've read through chapter 10 of your book a few times through, and although I think It's brought a lot of clarity to me... this issue has me stumped.

So, hopefully this clarifies my situation a bit better... if this is still possible and I'm a dummy and missing it... I'd absolutely love some further direction..

If not..how do I go about reopening the Feature request that was prematurely closed? Do I just start a new one?

Greatly looking forward to any feedback!

Sincerely,
-Jared [ed. note: jaredloman last edited this post 14 years, 8 months ago.]

Your original request was related to templates, not resources. Templates are hidden with an Element Category Access ACL entry and resources with a Resource Group Access ACL entry. If I suggested that you put resources in a category, that was a mistake (I don't think I did, but I'm too lazy to check).

Back to your issue. Only resources are associated with a context. Among all the other fields, like pagetitle and editedon, there is a 'context' field. Elements (templates, TVs, plugins, chunks, and snippets), OTOH, are free agents. They have no 'context' field and are not associated with any context, so there's no way for MODX to know when to show them.

One solution (at least for the resources) would be to teach the user to collapse the resource tree for the context he's not working on. For Templates, I'd prefix the template name with the sitename (dogTemplate1, lawnTemplate1).

Another solution would be to create two separate users, one for working on each context (e.g. JohnDog and JohnLawn), and have the user log in to the context he means to work on. Of course that would mean he couldn't copy text from one to the other. I've actually done this to make things simpler for users who are not very tech-aware.

If you wanted to get fancy, I think you could hide the template field with Form Customization and use an @INHERIT TV to show a drop-down list of appropriate templates, then write a plugin that set the actual template field based on that TV in OnBeforeDocFormSave.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/modx.html

Quote from: BobRay at Feb 04, 2012, 10:42 PM

Your original request was related to templates, not resources. Templates are hidden with an Element Category Access ACL entry and resources with a Resource Group Access ACL entry. If I suggested that you put resources in a category, that was a mistake (I don't think I did, but I'm too lazy to check).

Bob, thank you very much for your insight, and sorry for the confusion on the above text. I think that between only having 140chars to type on twitter and my lack of solidity in using proper modx terms that I've came across as confusing.

Quote from: BobRay at Feb 04, 2012, 10:42 PM

Elements (templates, TVs, plugins, chunks, and snippets), OTOH, are free agents. They have no 'context' field and are not associated with any context, so there's no way for MODX to know when to show them.

Thanks for the confirmation on this! My original feature request was to essentially allow Elements to be associated with a context (specifically templates) for scenarios like the above.

I think that creating two separate users accounts as well as two respective users groups, policies, etc will be my only solution in this case, although your last idea sounds very intriguing (albeit slightly out of my comfort level)!

All this being said, would something like this be a valuable feature to you or anyone else? I can't imagine that my current situation and the fake situation would be the only scenarios where this would come into play..

Thanks again!
-Jared

I'm not sure what the roadmap is for contexts and elements. My gut feeling is that the added overhead and complexity would not be worth it. It would add another level of complexity for security permissions, which many feel are too complicated now.


That said, I can imagine uses for context-related elements, and I think the ultimate plan is for elements to become more generic (with resources possibly becoming elements), so what you're suggesting could be part of that.



---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/modx.html

I would think that plugins would be useful here, although caching pages wouldn't be possible in that case since a cached page doesn't bother checking templates. Unless caching can be done per context.

The plugin would have to alter the code of Manager page based on the context of the doc. I think it could be done, but it might be easier to use the TV trick I mentioned above.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/modx.html