We are using CouchCMS and within that, the extended-users plugin for quite some years now. We are using Couch to manage the site of our sports club and have extended it with a lot of functionality, like a news letter function but also to calculate the monthly fee for each member, to send an email about that to each member and to prepare the monthly XML file to upload at the bank (to collect the monthly fees). How this roughly works is that we used the extended-users plugin to add four fields, each for a different category of fees, and that (using a template that utilises the extended-users plugin) we are entering the values for those four fields each month for each member. Each member is a user in the extended-users plugin, users can also login and see the members-only page.

So far, I was treasurer and also web master of the club and I was performing the above without any troubles. Recently, I have handed over the treasurer role to a new treasurer. The new treasurer can enter the values for the four fields for most but not all members: for two members it does not work. For these, CouchCMS displays the text "Cheating?!". When I use my own account all works, for all members.

My initial thought was that this must be a permissions problem, and I found that our template, which utilises the extended-users plugin, does not mention the access_level of the template. I have now changed that to access_level 7, thinking that maybe access_level 10 is default and therefore it worked for me, since I was (and still am) web master and own the super admin account.

Code: Select all

<cms:template clonable='1' title='Twirl Accounts' order='11' parent='_modules_' access_level='7'>

But, even with this, it still does not work for the new treasurer. But then I realised that, if it would have been a permissions problem, it would not have worked for any member, instead of only for two. I can reproduce the problem when I log in with the account of the new treasurer.

What could be going on here, is it some database level setting, or corruption, or something else? All help appreciated!

[trendoman]

What could be going on here, is it some database level setting, or corruption, or something else? All help appreciated!

Before any troubleshooting begins, it may be fruitful to delete and create one of that user record again. Can you try this?

I will try this, however will have to wait for the month to be passed since I can only reproduce this on our production environment which we need for the monthly processes right now. As soon as I have tried this, I will post the result here.

[trendoman]

I will try this, however will have to wait for the month to be passed since I can only reproduce this on our production environment which we need for the monthly processes right now. As soon as I have tried this, I will post the result here.

Any Couch installation can be fairly easily cloned, so I advise to investigate the issue offline and make changes on production only after confirmed successful changes on the local copy.

We have a doc about migrating to production (Migrating from development to deployment server https://docs.couchcms.com/miscellaneous ... erver.html) which should not be used "in reverse", because production has a filled-in database (usually helpful to investigate).

Here is a recap on best practice I usually follow:

• Create folder (domain) on localhost server and name it "yoursite.local", copy every file from production there
• Clone /couch/config.php into /couch/config.local.php and amend the top section of original config.php and (afterwards edit values of the file "config.local.php" which will be exclusively loaded for the localhost site with TLD ".local"):
  
  

  Code: Select all

  <?php
  
      if ( !defined('K_COUCH_DIR') ) die(); // cannot be loaded directly
  
      // !.
      // Check if a custom config for localhost dev domain exists and domain is .local
      // Otherwise proceed with default configuration.
      if ( file_exists(K_COUCH_DIR.'config.local.php') &&
          pathinfo($_SERVER['SERVER_NAME'], PATHINFO_EXTENSION) === 'local' ){
          return require(K_COUCH_DIR.'config.local.php');
      }
  
      // 0.
      // Set the following to 1 to put your site in maintenance mode.
      // In this mode only admins will be able to access the site while the visitors will be
      // shown the 'Site undergoing maintenance' message.
      define( 'K_SITE_OFFLINE', 0 );
  
      // 1.
      // If necessary, define the full URL of your site including the subdomain, if any.
      // V.IMP: Don't forget the trailing slash!
      define( 'K_SITE_URL', 'http://yoursite.local/' );
  

  
  
• Clone database from production to localhost. Database of Couch has no dependencies on the domain so will work immediately without editing, as all paths to files are stored as relative, passwords will work fine, etc.
  
• Make sure the values in config.local.php reflect the change (K_SITE_URL, K_DB_NAME, K_DB_USER, K_DB_PASSWORD, K_PRETTY_URLS set to 0, K_USE_CACHE set to 0);
  
• Finally, open /couch/header.php and disable snippet caching by setting following to 0, in order to always rely on live edits in files (both settings appear around line 60):
  

  Code: Select all

      define( 'K_CACHE_OPCODES', '0' );
      define( 'K_CACHE_SETTINGS', '0' );
  

That done, I restart the localhost server and it works as if in production. As a side effect, weaklings in code will reveal itself more brightly i.e. absolute paths in links (which should be relative with <cms:show k_site_link/> or generated by Couch with <cms:link />) and other small time issues.

Thanks all for your input. And yes we have a (local) test environment but the issue was not visible there.

Finally, by performing the action proposed by @trendoman, I was able to find the root cause of this and solve this. The two accounts for which no edits could be made were 'admin'-level accounts. So another admin-level account (that of the treasurer) could not change them, not even the monthly amounts. I have now demoted those accounts to normal acounts (authenticated user) and created two new admin-level accounts for administrative tasks usage.

Problem solved! Thanks again for your inputs, all functioning here again and confirmed by our treasurer