13 replies to this topic

[foxp2]

the idx_whos_online_customer_id constraint allows this.
in my opinion, it's not a good idea.
this constraint should be :

ALTER TABLE osc_whos_online add CONSTRAINT idx_whos_online_customer_id FOREIGN KEY (customer_id) REFERENCES osc_customers (customers_id) ON DELETE RESTRICT ON UPDATE CASCADE;

maybe, i'm wrong ...

[Harald Ponce de Leon]

Hi Laurent..

This could possibly be better handled at the software level rather than the database level. If it is set to restricted at the database level, then it becomes impossible to delete a customer if they are logged on. If a check is performed at the software level, the administrator can atleast be warned that the customer is still logged on and can choose an appropriate action (confirm or skip).

What do you think?

Kind regards,

[foxp2]

hi harald,
In March 24, 2011, you wrote in an article, intituled "open source rocks" : We want to be at the core of e-commerce!
i think during the development of  the framework, each customer must to be at the core of oscommerce.
in no case, administrator's actions should not have the priority over than the customers actions doing.
that's why i prefer a constraint 'RESTRICT' in the database.

[Harald Ponce de Leon]

Hi Laurent..

So to delete a customer that is logged on, the entry in the whos_online table must be first deleted before proceeding to delete the customer?

How do you envision the scenario of deleting a customer that is logged on? (for a real customer and a fake customer/spammer)

Kind regards,

[foxp2]

hi harald,

for a real customer ? if he's logged on : forbidden action.

for a fucking spammer or fake customer ? block them !

- > customers_status :
--> 1 enabled
--> 0 disabled
--> -1 blocked by administrator. --> unset his session (like the reset() method in osCommerce\OM\Core\Site\Shop\Customer.php)

[Harald Ponce de Leon]

Hi Laurent..

Yes, it's true that it would not make sense to delete a fake account without an ability to ban identifying information (eg, email address, ip address) otherwise they can create another account with the same information.

I understand your point of view better now, however I still think it would be better to give the administrator the possibility of forcefully deleting the customer or not. If the constraint is added at the database level, no such user-end feature would be possible.

Hopefully others can jump in and provide their thoughts on this to come to a conclusion.

Kind regards,

[foxp2]

we can block customers with something like that

action -> login :
\osCommerce\OM\Core\Site\Shop\Account.php :

/**
* Checks if  customer status is blocked with the provided e-mail address
*
* @[member='param'] string $email_address The e-mail address to check for
* @[member='access'] public
* @[member='Return'] boolean
*/
	public static function checkStatus($email_address) {
	  $OSCOM_PDO = Registry::get('PDO');
	 
	  $Qcheck = $OSCOM_PDO->prepare('select customers_id from :table_customers where customers_status = 1 and customers_email_address = :customers_email_address limit 1');
	  $Qcheck->bindValue(':customers_email_address', $email_address);
	  $Qcheck->execute();
	  return ( $Qcheck->fetch() !== false );
	}

\osCommerce\OM\Core\Site\Shop\Application\Account\Action\LogIn\Process.php :

<?php
/**
* osCommerce Online Merchant
*
* @[member='copyright'] Copyright (c) 2011 osCommerce; http://www.oscommerce.com
* @[member='licensed2kill'] BSD License; http://www.oscommerce.com/bsdlicense.txt
*/
  namespace osCommerce\OM\Core\Site\Shop\Application\Account\Action\LogIn;
  use osCommerce\OM\Core\ApplicationAbstract;
  use osCommerce\OM\Core\Registry;
  use osCommerce\OM\Core\Site\Shop\Account;
  use osCommerce\OM\Core\OSCOM;
  class Process {
	public static function execute(ApplicationAbstract $application) {
	  $OSCOM_NavigationHistory = Registry::get('NavigationHistory');
	  $OSCOM_MessageStack = Registry::get('MessageStack');
	  if ( !empty($_POST['email_address']) && !empty($_POST['password']) ) {
		  // check address email
		  if( Account::checkEntry($_POST['email_address']) ) {
		  // check first if status = 1
			if( Account::checkStatus($_POST['email_address']) ) {
			// check account
			  if( Account::logIn($_POST['email_address'], $_POST['password']) ) {
				$OSCOM_NavigationHistory->removeCurrentPage();
				if ( $OSCOM_NavigationHistory->hasSnapshot() ) {
				$OSCOM_NavigationHistory->redirectToSnapshot();
				} else {
				OSCOM::redirect(OSCOM::getLink(null, OSCOM::getDefaultSiteApplication(), null, 'AUTO'));
				}
			  OSCOM::redirect(OSCOM::getLink(null, OSCOM::getDefaultSiteApplication(), null, 'AUTO'));		
			}
		}
			$OSCOM_MessageStack->add('LogIn', 'account blocked !'); 
		  }else{
		$OSCOM_MessageStack->add('LogIn', OSCOM::getDef('error_login_no_match'));
		}	   
	  }else{
	  $OSCOM_MessageStack->add('LogIn', 'email address and password are required !');
	  }
	}
  }
?>

just a suggestion...

[toyicebear]

Harald Ponce de Leon, on 31 January 2012 - 09:10 PM, said:

I still think it would be better to give the administrator the possibility of forcefully deleting the customer or not. If the constraint is added at the database level, no such user-end feature would be possible.

I agree. I see no reason to limit the administrators possible actions at the db level, keep such options open and add restrictions/warnings in the code.

Edited by toyicebear, 01 February 2012 - 01:00 PM.

[foxp2]

now, in the back office :
[attachment=950:backofficecustomer.PNG]
yes, my customers are famous !

Edited by foxp2, 01 February 2012 - 02:58 PM.

[Harald Ponce de Leon]

Hi Laurent..

Yep, that looks nice!

What are the three states you're showing?

Green: Active
Yellow: ?
Red: Blocked

Kind regards,

[foxp2]

Hi Harald,
Yellow : inactive.
actually, in the code (exactly in the createEntry method \osCommerce\OM\Core\Site\Shop\Account.php) the customer status is hardcoded.
but we could adding an option (like Confirm  Account Creation Procedure - true [by default]/ false)  in Configuration: Regulation) to activate an account :
eg :
- manually
- with a confirmation link in an email
- etc

dashboard :
[attachment=951:backofficedashboard.PNG]

[foxp2]

join operation added in execute() method for osCommerce\OM\Core\Site\Admin\Application\Customers\SQL\MySQL\Standard\GetAll.php class
session_id added in result array (usefull to kick off spammer/fake account if logged on)
new colors for account legend :
gray : block
red : inactive
green : active

[attachment=954:backofficecustomer.PNG]

that's all for now.

[foxp2]

added : cookie tracker for the lastest action :
[attachment=960:backofficecustomerwithcookieinformation.PNG]

pending : storing action in osc_administrators_log table.

[Foayiid]

Quote

@Foayiid:
What do you expect from this feature ?

Hi Laurent,
I'm following this interesting subject.
I'm wondering if the effect will be different on the catalog between a 0 (inactive) and -1 (blocked) customer ?