Forum OpenACS Development: ad_proc [cc_email_user] returns blank

Hi there,

I've noticed that ad_proc [cc_email_user $email] has stopped to return the user_id, but only for new users.
The problem started after I moved user-new.tcl script to a custom pkg and customized the registration form, adding one more field.

Even though I had copied the whole TCL script into the new file, it seems the execution of registration process has broken at some point, that new users are not 100% persisted into database anymore.

Maybe, moving the registration outside acs-subsite could have broken something related to auth ad_procs. I've debugged every line of acs-subsite/lib/user-new.tcl but I found no references to extra scripts or callbacks whatsoever.

Should I be looking somewhere else?

Best wishes

Collapse
Posted by Iuri Sampaio on
Going further on debugging, the email has been storaged on table acs_users_all.

Context:
ad_proc cc_email_user runs the private ad_proc cc_lookup_email_user, which runs the SQL line as follows.

select user_id from acs_users_all where lower(email) = lower(:email)

Furthermore,
By runing the query alone within pgsql shell prompt, the user_id is properly returned.

Thus, I have flushed the memory and restarted NaviServer, but the problem still persists.

Best wishes

Collapse
Posted by Antonio Pisano on
Mmm... if data for user is properly stored into database I don't see why proc should not return what is supposed to.

Just out of curiosity, what happens if you replace cc_email_user with its non-deprecated alternative party::get_by_email[1]?

Ciao

Antonio

[1] https://openacs.org/api-doc/proc-view?proc=cc_email_user&source_p=1

Collapse
Posted by Iuri Sampaio on
party::get_by_email -email $email works just fine.
Collapse
Posted by Iuri Sampaio on
The same happens to [parameter::get]. I've just created a new parameter, which belongs to a new custom pkg.

Then, I try to get its info but it returns blank.

set token [parameter::get -parameter "WebAppAccessToken" -package_id 15689]

Noticing that parameter::get returns value to core existent params.

parameter::get -parameter "PortletTemplate" -package_id 4796
Returns: /packages/banners/templates/banners-portlet

I do remember that Gustaf mentioned some enhancements, in a previous forum thread, plus there's a new ad_proc to solve the problem. I'd need to look at api-doc its prototype.

Best wishes,

Collapse
Posted by Iuri Sampaio on
Here it goes

set token [parameter::get_global_value -package_key "evex-rest" -parameter "WebAppAccessToken"]

which brings global and instance contexts.

Would make sense an enhancement to parameter::get to have a new argument? (i.e. -scope "global/instance")

api-doc/proc-view?proc=parameter%3a%3aget&source_p=1

Collapse
Posted by Iuri Sampaio on
Bottom line, two subjects:

1. cc_email_user and party::get_by_email; and

2. parameter::get and parameter::get_global_value;

Best wishes,

Collapse
Posted by Gustaf Neumann on
Iuri,

1) you should replace deprecated calls by non-deprecated calls. Nobody will fix deprecated calls. OpenACS warns you, when you use deprecated calls.
2) parameter::get_global_value is not really new, it was introduced in 2010 [1]
-g

[1] http://cvs.openacs.org/browse/OpenACS/openacs-4/packages/acs-tcl/tcl/parameter-procs.tcl?r1=1.17&r2=1.17&u=3

Collapse
Posted by Iuri Sampaio on
Oops,
I knew about 2, but I didn't about 1! I should have looked at /api-doc in OpenACS.org, instead of my own box.

Thanks Gustaff

Collapse
Posted by Iuri Sampaio on
Even though, I found the reference to cc_email_user within /packages/acs-authentication/tcl/authentication-procs.tcl , line 216

...
set user_id [cc_lookup_email_user $email]
...

There's a core change that must be applied.

Best wishes

Collapse
Posted by Gustaf Neumann on
not sure what you mean: which change on the core do you think has to be applied to which version of the core to get which effect?