I create a post and set the Access Level to "Administrator" so that I can see how it appears within my site (just clicking VIEW only shows me the page view of it). Although this blocks general users from seeing it (they get the login page) it still appears on any list view of the template. Bug? or am I doing something wrong?

[trendoman]

I create a post and set the Access Level to "Administrator" so that I can see how it appears within my site (just clicking VIEW only shows me the page view of it). Although this blocks general users from seeing it (they get the login page) it still appears on any list view of the template. Bug? or am I doing something wrong?

I hope you are talking about frontend. I can suggest something here.

As long as cms:pages fetches all the pages, regardless of their access_level by default (excluding only by some other parameters as in docs), you can construct list_view without your protected pages by:

1. unpublish your page
2. exclude it with cms:pages id='NOT {id of your page here}'
3. move to specific folder, named 'admin' and exclude folder 'admin' from query: cms:pages folder='NOT admin'
4. move date to some distant future, as cms:pages by default doesn't show_future_entries.
5. Create a conditional statement inside cms:pages block: <cms:if k_user_access_level le '5' > .. list pages .. </cms:if> It will show only unprotected pages for users with access_level 0, 2, 4, effectively filtering out pages with level 7 -admin and 10
- superadmin.

There are some other ways, but these should be just enough.

Hope it helps Let me know which you used in the end.

REALLY!? I can't understand why setting an access level would only restrict the post from view on the single page view but not the list view. Unless you wanted someone to pay-to-join so that they could read the full body of your post (I've seen some sites that do that!). At a minimum, I would assume there'd be a parameter in the pages tag that would allow such filtering. Something like "observe_access_level_setting".

Actually, I would think you should be able to use the custom_field to do something like this:

Code: Select all

<cms:pages custom_field="k_access_level<=k_user_access_level" >

But this doesn't work! I get an error saying the k_access_level doesn't exist in the template (why not? where is it? It shows up in a dump!).

Furthermore, in experimentation, I tried using a different pages tag based upon user access level:

Code: Select all

<cms:if k_user_access_level ge '7' >
   <cms:pages orderby='publish_date' order="desc" folder=k_folder_name >
<cms:else />
   <cms:pages paginate='1' folder=k_folder_name limit='10'>
</cms:if>

But that gives me an error on my "else" statment!

I suppose the only answer is to put some kludge workaround code as your solution #5 but still wouldn't address the ability to change parameters of the pages tag based upon the access code.

[trendoman]

@wysocki, thanks for your input, I'm sure @KK takes all suggestion seriously. We can always find something that is missing, that's an everyday situation and a motivation to keep learning.
So, what is exactly that you need help with?

At this point, I broke down and put a big condition <cms:if k_user_access_level ge k_access_level > just inside the pages loop. Not a major issue at this point since I have only few pages. However, if I had a huge database, I'd like to not retrieve all those records that I don't want to use. It's just not clean. And given the great custom_fields parameter, it's kind of crazy that you can't use it to do this filtering too.

[trendoman]

At this point, I broke down and put a big condition <cms:if k_user_access_level ge k_access_level > just inside the pages loop. Not a major issue at this point since I have only few pages. However, if I had a huge database, I'd like to not retrieve all those records that I don't want to use. It's just not clean. And given the great custom_fields parameter, it's kind of crazy that you can't use it to do this filtering too.

@wysocki, well that's great then Does it work for you the way you require? In the end of the day what really matters is if it's delivering. I hope you'll believe me, that sometimes i feel the same, but after some time realize what really matters is the working function. Custom fields are destined to work only for custom, i.e. defined by you, editable fields.

If you want to experiment further, there is a setting in cms:pages - return_sql='1'. It will allow to see the actual query to MySQL database which cms:pages constructs and then sends, asking mysql to deliver. Then, a proper sql query can be sent directly with cms:query tag, thus effectively achieving any goal. If you wish so, I could try to find a way to send a condition in such a query to exclude pages with a certain access_level. So Mysql wouldn't fetch it in the very first delivered results.

I knew this "if" statement technique would come back to haunt me. The homepage of my site has a section called "5 Latest Posts" (with a "LIMIT=5"). I have a couple of new posts that I created with access just for members to see but if someone not logged in sees the list, there are only 3 posts in it!!!

[trendoman]

I knew this "if" statement technique would come back to haunt me. The homepage of my site has a section called "5 Latest Posts" (with a "LIMIT=5"). I have a couple of new posts that I created with access just for members to see but if someone not logged in sees the list, there are only 3 posts in it!!!

Then I would really think into assigning a folder for such posts. Then limit would be executed correctly, fetching pages from any folder, except the one that you destined to become a holder for restricted posts.

Anton:
I appreciate your suggestions, but I have to believe that workarounds must only be temporary in nature. I need to avoid them because I will not be in charge of this website forever. Someone else will have to pick it up and besides probably not being versed in Couch, I can't have the complication of exception based code in the system.

In this case, since I can't predict folders the user will create in the future, I have the main list page showing posts from all folders. If I create an "admin" folder, then I not only have to write code to hide those posts, but I have to hide that folder from my "folders" listing to the user! Who knows where else they'll pop up to cause trouble. For example, right now, with my <cms:if...> I notice that my "access controlled" posts still add into the archive counts.

Bottom line, if you're gonna have a feature to set an "Access Level", it should control access to that class. Period. Everywhere.

[KK]

@wysocki
Following is a quote from the docs (http://docs.couchcms.com/concepts/users ... ss-control) -

To be honest, the access mechanism currently implemented is fairly coarse (you can expect some major changes in the coming versions).

Sadly, that remains the status-quo as things stand right now. The planned revised access control mechanism would be much different from the rudimentary one we have right now. Till that happens, I regret to say, this is all we have to offer in terms of access control.

That said, you mentioned in your original post -

I create a post and set the Access Level to "Administrator" so that I can see how it appears within my site (just clicking VIEW only shows me the page view of it)

.
That is precisely what the 'unpublished' setting is for. For newly created pages, keep them unpublished till the admins are through with the review. For reviewing changes to existing pages, use 'drafts' for the review purpose. Any problems with the standard approach?