"user_submitted" flag is set to TRUE even though it was never set.
| Project: | Domain Access |
| Version: | 6.x-2.0-rc5 |
| Component: | - Domain Prefix |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
For the three new domains i created today on our server, the "user_submitted"-flag is somehow set to True. This has the consequence of us not being able to create new or modify existing prefixes for those tables. It does work of course, when you set the domain_user_prefixing variable in the domain_user_form to true as well, but since we do not allow user-domains anyway, this seems not to be the source of the problem (but if this should be the correct behavior, domain_user_prefixing should be set to true by default).
Short summary of where i looked until now:
domain_prefix_form_submit in domain_prefix.admin.inc does not enter the big if statement. This is because domain_user_prefixing is set to 0 which is default for the domain module and it makes sense this way as long as you are not using the user domain feature (which we don't).
After that i started to look where the user_submitted-flag gets set in the domain module. There are actually only two files:
domain.admin.inc:
- in domain_[create|edit|delete]_form_submit the form_state gets checked (and you are actually only redirected and get the success message, if "user_submitted" is empty or not set, which was always the case)
- as an argument in domain_[create|edit|delete]_form, where i could not see "user_submitted" being passed to those forms or actually being generated as a hidden field in the html-output.
- domain_configure_form, which gets it as direct parameter but never uses it.
domain_user.module
- in the hook_user implementation which only gets relevant at the creation or update of a user, which has not happened (here i am actually not exactly sure: but i am doing this as a drupal-root and i created many domains with this user without setting this flag, also the user account has not been updated in the relevant time frame).
I have no idea where to go from here, and seems a bit inconsistent to me, so i am issuing a bug. It is probably just a support request ;-)
Thank you for your time.
#1
Another probably relevant observation:
all newly created domains expose "domain_arguments" as new table for prefixing. i guess that this table is for the view integration, to set view arguments specific to each domain? our 18 old domains do not expose this table and there is no table in the database with this name (which means also no way to copy from the default domain). if domain_arguments - contrary to my above guess - is actually the place where the argument arrays should be stored than this could be the source of my problems. But i still can't find an initialization of "user_submitted" that would support this.
#2
This is all very difficult to follow, but I think it is just misconfiguration.
The 'user-submitted' flag should only be present if Domain User is active. If you are not using it, turn it off and uninstall it. Not all modules in the suite need to be activated (in fact, only Domain Access itself is required.)
There is no 'domain_arguments' table provided by any of the modules in the download. Use the schema module (http://drupal.org/project/schema) to determine where that table is being defined. It isn't in any code that I have released.
#3
sorry if that was a tad confusing.
I followed your advice to uninstall domain_user and that solved the issue with creating/updating prefixes as well as the issue with the ominous "domain_arguments" prefix entry (at least for newly created domains after the uninstall of domain_user).
I still was curious how the "domain_arguments" got into the list of the prefix-admin and the answer is that there were actually entries (WHERE tablename = "domain_arguments") in the "domain_prefix" table for the respective domains. I think it is possible for the
$form_state['values']['domain_arguments']to slip through under certain circumstances (which are way above my head atm). But since you assign$data = $form_state['values'];in line 391 of domain_prefix.admin.inc and your
$key,$valueand part of$form_stategets inserted in line 481, the easiest fix for such a slip would be to add'domain_arguments'to the$unsetarray in line 390.anyway, from my point of view the issue can be closed.
thanks again for your support.
#4
sorry, that patch was against 6.x-1.2
this one is against 6.x-2.0-rc5
#5
Got it. Thanks!
I may have to do something more complex, since the list of tables is supposed to be taken from the schema, and I have to see why that is not the case.
#6
I think that #424830: Domain prefix (updating tables) page not updating when submitting page post. is the proper fix.
#7
#8
Automatically closed -- issue fixed for 2 weeks with no activity.