You will just want to set a *read permission rule to "Anyone Signed In" and apply it to *all cards. There is no set-based way to delineate only newly created cards, so this will apply to all cards that don't have a narrower rule.
I thought so... maybe it's WEBrick but doing this to all cards just freezes everything. Last log before freeze:
took out the log, it was too long you can see it in history...
WAIT, IT'S JUST SLOW... finished after about a minute.
But it doesn't seem to work. I can Sign Out and see any page I like. Including a card I just created. I can even browse the rule page of the card saying just "Anyone signed in"
Morning update. I've tested it a couple of times. It seems that deleting the tmp fixes this issue. It's as if the system is still using cache after I modified the *all+*read. Tested it both on nginx and WEBrick.
Later note. It seems the 'recents' page survives even tmp folder deletion. Newer cards created after setting Anyone signed in don't seem to show up, as expected, but cards created before that do. They only show up in search though, trying to access them shows a sign in page as expected.
WAIT... it seems after 5 min the recents page has "refreshed" itself and cards created before the Anyone signed in setting are not showing up any more. Either passing the time has fixed the issue OR traveling to all the pages including the last one (about 26 in total if memory serves) in that search has somehow caused it to regen (I was checking it page by page)
Kind of wierd that the recents page is visible to people who haven't signed in, in any shape or form. It seems to be excluded from the *read setting. Now it only seems to show two pages of system cards, nothing else is visible. I can understand that the other pages are needed to display basic login and layout but an actual search page displaying these, I don't know.
Slowness: The *read permission is unlike any other rule in that it can update rows in the database for cards that it applies to. This is because when we do queries, we only want to return cards that the user has permission to read, and sql can't do rule processing on the fly. But this particular update shouldn't be slow, because it's not changing the cards applied to, only the value of the rule. I'll have to look into that.
Cache: I would recommend you start using memcache. I've never heard of anyone having so many cache problems, but in general memcache is smarter and faster, so it's worth the switch. We like to use the gem dalli and set `config.cache_store = :dalli_store, []` in application.rb.
If you're switching between two different servers, it's possible that you've got two separate caches of the system, and that's leading to lots of confusion. I would recommend clearing the cache whenever you switch to a different server or a different environment using the same database.
The recents page is just a card named *recents. By default it has its own permissions rule allowing users to read it. This is because it was linked to from the home page. Thanks to the query handling mentioned above, the only cards showing up will be those that you have permission to read. If you want to change permissions on the *recents cards, that's very simple. I would just go to advanced > rules and then delete the current rule.
It works! Just made the *recent card private to Anyone Signed in.
There is however the same "lag". To replicate it. Choose a public card and make it readable by Anyone Signed In only. Log out. Notice you can still see the card even is you are Logged out. My impression is that the system has an already cached version of the card which it finds first and displays, so It goes around the new permission you put in (can't be sure, but I think it might be wagn doing it because on nginx I haven't explicitly enabled any caching). Wait a while and try to refresh the page again, notice this time you can't see it as you aren't Logged In.
NOTE: On a peculiar note, the search content returned by *recent now has a new card +*self+*read displayed in it. It looks that it takes out the *recent, because the real name is *recent+*self+*read. Interesting.
hahaha. Yes, that's standard behavior, which is usually helpful but in this case it's pretty weird, huh?
In this case yes, but I can live with it, it's just one those things that really occur once. If this hasn't crept up until now I guess not many people make their site entirely private.
NOTE: this 'cached' behavior seems to survive a restart too. Deleting the tmp folder, restarting and then accessing it again seems to force a refresh.
Q: Is Wagn generating .html or some kind of files off of each card you access so it can serve them faster? How does this process work?
Sorry, I was in a hurry today and was only responding to your NOTE above.
The lag behavior is definitely not standard; I can't replicate what you're seeing, for example, on test.dwagn.org. Just tested and it worked as you would expect. Something is really wonky with your cache handling. Are you using dalli / memcached?
At present, no we don't cache pages, we cache card objects.
I'm using wagn on nginx with no explicit caching so I really have no idea. I'm interested on how you cache card objects, but I'll start another thread.