Interaction issue with submission accounts

[doomlab]

@benkeen

This may be related to submission accounts error # 1 ... I have a video of what is happening on our site: https://www.loom.com/share/703012f796a04004a8de7a22db1e2e8d (I will email you the password).

In digging around more, I think it's because the index.php in the admin folder redirects to /forms/, which then is doing something odd because of the cross talk in variables?

I killed the issue on the admin page by just redirecting to /formtools/ main directory, but I am unsure how to fix the problem on the /formtools/admin/forms/ page because it does still give access that I don't want to do. Can I implement something like the suggestion here: formtools/module-submission_accounts#1 ?

Thanks!

[doomlab]

Did finally find a workaround that doesn't allow people to see pages they shouldn't:
in User.class.php --> line 374

		if ($account_type == "user") {
			if($required_account_type == "admin")
			{
				$boot_out_user = true;
				$message_flag = "notify_no_account_id_in_sessions";
			} else if ((!Sessions::exists("account.submission_id") || General::isEmpty(Sessions::get("account.submission_id"))) && General::isEmpty(Sessions::get("account.account_id"))) {
				if ($auto_logout) {
					General::redirect("$root_url/modules/submission_accounts/logout.php");
				} else {
					$boot_out_user = true;
					$message_flag = "notify_no_account_id_in_sessions";
				}
			}
		} // check the user ID is in sessions

Looks like if the person is user, it was never really checking on a page if they should actually have admin rights - and then the else if of client/user or else admin basically was never triggered because the user if never booted them out.

[MABOY242]

Thank you, I noticed this same bug last week. Your solution fixed the issue for me--hopefully someone at FormTools fixes this bug in a future upgrade/patch.