We've used authentication logic in the display method (shudder) to limit
visitor access to the content - eg, displayArticleMembersOnly with a
redirect to a login page or other display node, or
displayArticleByPermissions which uses either an abridged or full version of
the content depending on whether the user is logged in and their role
membership.
HTH
Chris
If a sysadmin is logged in he would have access to all
templates/display methods for both domain 1 and domain 2.
Is this possible to do in farcry, or is the only solution to have two
separate farcry sites?
There is presently nothing in FC that will allow you to associate a
template w/a site, but you could come up w/a naming scheme that include
the site name (or hard code it into the selector itself :-( ).
The real challenge will be that you have to do this for every single
type that you are using. And when FC moves on w/ updates, you will have
to manually upgrade every single type b/c farcry_core code is not executing.
This is the code that would be affected for each type:
<cfimport taglib="/farcry/farcry_core/tags/navajo" prefix="nj">
<nj:listTemplates typename="dmHTML" prefix="displaypage"
r_qMethods="qMethods">
<cfoutput>
Display Method:
<select name="DisplayMethod" size="1">
</cfoutput>
<cfoutput query="qMethods">
<option value="#qMethods.methodname#" <cfif qMethods.methodname
eq output.displaymethod>SELECTED</cfif>>#qMethods.displayname#</option>
</cfoutput>
<cfoutput>
</select>
Note (do this w/trepidation): you could also go in and simply change the
/farcry/farcry_core/tags/navajo/listTemplates.cfm in the core. You
would have to be careful when doing upgrades, as that file would be
overwritten every single time, which would require a manual restore of
the one file.
Scott Talsma-2 wrote:
The easy way out is to have two sites. The you can simply remove the
unused display methods from the webskins. But if you really want to do
it, it should be possible. You will have to override the cfc (copy it
into project/packages/types) along w/ supporting files. You would only
want to override the edit method, and its only change is that before
displaying the list of templates, you filter it based on the current user.
This is the approach I'd recommend myself. We toyed with the idea of adding an another "special" comment to templates (for example, like the @@displayname: comment) that includes a list of roles that are allowed to select a template. I wonder if this is something that would be of interest to the general community?...snip...8<
If <!--- @@permission: publisher ---> exists publisher would have
access. And so on.
If the "permission special comment" don't exists everyone would have
access =)