8/23/2025 6:28:12 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Failure to update SECCODEID on secured tables 1:1 against A/C/O/T
Posted: 17 Mar 08 12:59 AM
|
Reported to Sage Australia today:
This is a significant and nasty problem, first unearthed at but which will affect all other customers who have 1:1 add-on tables attached to Account and Contact.
Background: If the add-on tables were flagged as “Enable Field Level Security”, the Database Manager adds a SECCODEID field. The SalesLogix application then uses that to manage which Field-Level Security profile to use. However, it also gets used by the provider to show or not show those add-on records. When you change the Owner (SECCODEID) on an Account using the SalesLogix Client interface, it makes the same change automatically to tables like Contact, Opportunity, etc.
Issue: Although SalesLogix.exe (I guess) updates the tables it knows about, it totally misses any 1:1 add-on tables that had a SECCODEID added to them as a result of you selecting “Enable Field Level Security” when you created the tables.
Proof: (minus the bundle referred to - available upon request). Sorry the formatting gets lost - I have it in a Word document if needed.
1. Take a vanilla SalesLogix 7.2 database and apply the bundle below, that consists of:
a. Two add-on 1:1 tables, i.e. one each against Account and Contact. These tables were created in the normal way, with the Enable Field Level Security option selected. That causes it to add SECCODEID to each of the new tables. It is these fields that are not getting updated subsequently by SalesLogix.
b. Modified Account and Contact detail screens. Each has a couple of green fields at the bottom, being
i. A test field to force it to create add-on records in the tables above.
ii. A read-only field to show what is in the add-on table’s SECCODEID field.
2. Create an Account called Adexio and a Contact called Paul Roussell, owned by Everyone.
3. Put a value into a TEST field on each of PW_ACC_MORE and PW_CON_MORE, to force those records to be created too. SECCODEIDs are all correct at this stage.
4. Run this SQL to check all SECCODEID values are correct.
SELECT sysdba.ACCOUNT.ACCOUNTID AS AccountAccountID, sysdba.ACCOUNT.ACCOUNT AS AccountAccount,
sysdba.ACCOUNT.SECCODEID AS AccountSeccodeID, sysdba.PW_ACC_MORE.SECCODEID AS AccMoreSeccodeID,
sysdba.CONTACT.CONTACTID AS ContactContactID, sysdba.CONTACT.SECCODEID AS ContactSeccodeID,
sysdba.PW_CON_MORE.SECCODEID AS ConMoreSeccodeID
FROM sysdba.PW_ACC_MORE INNER JOIN
sysdba.ACCOUNT ON sysdba.PW_ACC_MORE.ACCOUNTID = sysdba.ACCOUNT.ACCOUNTID INNER JOIN
sysdba.CONTACT ON sysdba.ACCOUNT.ACCOUNTID = sysdba.CONTACT.ACCOUNTID INNER JOIN
sysdba.PW_CON_MORE ON sysdba.CONTACT.CONTACTID = sysdba.PW_CON_MORE.CONTACTID
WHERE (sysdba.ACCOUNT.ACCOUNT LIKE 'Adexio%')
Results were:
AccountAccountID AccountAccount AccountSeccodeID AccMoreSeccodeID ContactContactID ContactSeccodeID ConMoreSeccodeID
A6UJ9A0000BG Adexio SYST00000001 SYST00000001 C6UJ9A0000BH SYST00000001 SYST00000001
5. Now on the Account screen change the owner from Everyone to something else (in my case, I used a Team called All Boeing whose SECCODEID = ‘F6UJ9A000006’). Notice it updated the Account and Contact owner fields, but not the similar fields on the add-on records.
6. Run the same SQL Statement. Results were:
AccountAccountID AccountAccount AccountSeccodeID AccMoreSeccodeID ContactContactID ContactSeccodeID ConMoreSeccodeID
A6UJ9A0000BG Adexio F6UJ9A000006 (Correct) SYST00000001 (Wrong) C6UJ9A0000BH F6UJ9A000006 (Correct) SYST00000001 (Wrong)
Case proven!
 |
|
|
|
Re: Failure to update SECCODEID on secured tables 1:1 against A/C/O/T
Posted: 17 Mar 08 11:23 PM
|
Hello Paul!
Were you under the impression that the product was supposed to cascade update the SecCodeID columns in your custom tables? I don't believe this is the case and would consider this a feature request. We have always handled this scenario with custom code.
In fact, I dont want Sage adding more black magic code to the system that assumes I want those columns updated. Furthermore, we have customers that dont want the current cascading to happen either. Just because an account owner changes does not mean that the child contacts and opportunities should change too. Now, this certainly may be the case for many implementations but the assumption that a business rule, ANY business rule, should apply to 100% of the customer base is bad form in my opinion.
Timmus |
|
|
|
Re: Failure to update SECCODEID on secured tables 1:1 against A/C/O/T
Posted: 17 Mar 08 11:59 PM
|
Hi Timmus - Long time no see/speak!
I understand your point. I think the issue here is that it is inconsistent. As we don't have control over the current black magic code, it should either
1. Do ALL updates including 1:1 add-on tables with SECCODEIDs in them
2. Do NONE of them, i.e. do not do C/O/T either (except that it should always keep ACCOUNTSUMMARY in sync of course)
3. Make it optional, based on architect/admin-defined parameters held on each table definition (e.g. in RESYNCTABLEDEFS, SECTABLEDEFS, or maybe JOINDATA - whatever makes sense)
In fact, I prefer option 2 right now. Is there any way to suppress the black magic bit, or to auto-undo it in something like onPostUpdate (or whatever the name is) please?
My new (large multinational  ) customer needs to be able to differentially set ownership on Contact and Opportunity. While that creates risks that the ownership of the Account might be limited and some people able to see the Contact might fail to see the Account, we are prepared to manage that. We actually only want thtis de-linking so that they can have differential combinations of Field Security. This is so that maybe only certain people can edit details on one specific Contact.
Many thanks.
Cheers, from Brisbane, Australia
Paul Roussell
PS See you at Insights? |
|
|
|
Re: Failure to update SECCODEID on secured tables 1:1 against A/C/O/T
Posted: 18 Mar 08 10:05 AM
|
Yes, it has been a long time. We may have to figure out a "work" reason to come out and visit later this year.  I have never been to your side of the world and would love the opportunity.
Odds are good that I will be at Insights. I look forward to seeing old friends and making new ones as well.
You have summarized the issue very well, Paul. I also agree with your preferrence for option 2.
For your implementation, you may be able to get what you need by handling the ownership change via code rather than databinding. If I am not mistaken it was the databinding engine that contained the black magic for cascading the update. With the web client I believe the legacy webdll would capture the ownership update and cascade the change. If you find that the provider is the culprit rather than the databinding engine let me know and we can discuss triggers as an option.
Hope this helps!
Timmus
|
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|