In my mind, you just did the good choice. Let's consider the situation where a user can ask for the 'ref' attribute : - he asks for all the operationnal attributes ( filter = '+' ) - he asks for 'ref' explicitely - he get a referral entry, and only if he added the ManageDsaIT control. - he has created an entry with the 'extensibleObject' OC and added a 'ref' attribute to this entry, using it for other purpose than referrals management
for the 3 first cases, we don't really care about returning 'ref' all the time : the user will only get it for found referrals, and only if he has added the ManageDsaIT control. Especially for case 1 and 2, there is no way he can get a 'ref' attribute (just because referral wont be returned as entries if the ManageDsaIT is not passed to the server). For case 4, well, I don't think we should bother. At least for 1.0.1. And even for 1.0.2. Let's postpone such a case for 1.5.0 (anyway, doe sit harm someone that a get the 'ref' attribute when he deliberatly added it into a special entry?) Emmanuel On 2/14/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Hi Emmanuel, I started adding code to inject the "ref" attribute into the returningAttributes property of the SearchControls to enable the detection of a referral. As I was doing this I had to make the attribute selection code add all attributes when just [ref] was found in the returningAttributes field since ref is synthetically injected. Sometimes though users will just want to have only the [ref] attribute returned and will specify that in the returningAttributes list. There is then no way for to differentiate between these situations when the user intentionally only requests the ref attribute verses when the server artificially injects it. So instead I altered the core code responsible for selecting attributes to always return the ref attribute regardless of whether it is specified in the returningAttributes list or not. This way if the user just specifies the [ref] attribute only that attribute will be returned instead of returning it and all the non-operational attributes. Now we only need to add some code that makes sure the ref attribute is removed from the entry if the *ManageDsaIT * control is enabled and the user did not explicitly ask for the ref attribute. This however is a very rare situation. Why would this control be enabled by a client without the intention of getting the ref attribute when a referral only has a ref attribute in it? I cannot think of a good use case for this. So I'm not going to bother adding code to remove the ref attribute at this point in time. Let me know if you think we still should and I can add it. Alex
-- Cordialement, Emmanuel Lécharny www.iktek.com
