Hope you are all doing good!!!.
I just need to fix this one and I googled the logic and when I tried I got an error and then I have copied the online code and paste that too but no use.
the logic of the below code is :Check the phone number of the account and compare old and new value of the phone number if it's not the same value then I need to update the old value in the description.
public class CheckOldAndNewValueonAccount {
public static void accNewOldValues(List<Account> accList){
for(Account acc: accList){
Account oldAcc = Trigger.oldMap.get(acc.Id);
if(acc.Phone != oldAcc.Phone){
acc.Description = 'Old Phone number this account is :'+oldAcc.Phone;
}
}
}
}
Error: Illegal assignment from SObject to Account.
Please guide me on this.
Thanks in Advance.
I believe the issue is this line:
Account oldAcc = Trigger.oldMap.get(acc.Id);
I believe the type of old map is Map<String, sObject>.
sObject is a type that is a Salesforce object (any one) but none specifically.
So you are trying to assign an sObject to a variable you are declaring as an Account type.
You can just do the following:
sObject oldAcc = Trigger.oldMap.get(acc.Id);
unless you specifically want to try and cast the sObject to an Account (concrete) type. I don't see any major benefit to doing so. Let us know if that was the problem and if this resolved it.
Edit: see this trailhead:
https://trailhead.salesforce.com/en/content/learn/modules/apex_database/apex_database_sobjects
Section: Casting Generic sObjects to Specific sObject Types
You can easily cast to Account. There is a snippet there.
Dot notation is not available on generic sObject types.
Or you can use .get('fieldname') which works on generic sObject as well.
Related
I want to track a guid value in LogAnalytics, using tracked properties, but I can't get it to be saved as a string (that is with suffix "_s" instead of "_g" for guid).
I've tried to convert it to string and to replace all the hyphens to empty string, but no luck.
It works fine if I concat the guid with another character, but I want to save the guid as it is of course.
Example, this does not work:
trackedProperties": {
"MessageId": "#{string(Outputs('MyAction').MessageId)}"
}
Anyone got an idea of how to solve this?
I think we need to refer to the official document to know the record type and properties.
So could you please check if the "messageId_g" is existed. And if still can't solve it, you can try to use another "Initialize variable" action and put your messageId in it and then tracked the property in "Initialize variable" action, it should be "_s".
Hope it helps~
To identify a property's data type, Azure Monitor adds a suffix to the property name. If a property contains a null value, the property is not included in that record. This table lists the property data type and corresponding suffix:
**RECORD TYPE AND PROPERTIES**
**Property data type Suffix**
String => _s
Boolean => _b
Double => _d
Date/time => _t
GUID (stored as a string) => _g
I'm trying to remove a member from a large ldap Active Directory (AD) group. The below code will remove the member if the group is small. However it won't work if it's larger since AD splits the members into multiple range related attributes.
group.removeMember(person.getFullDn());
ldapTemplate.update(group);
I've tried to access those attributes directly using something like the below. IncrementalAttributesMapper allows me to get the list of range related member attributes ie member;Range=0-1499 and I attempt to delete the person from each, but no good. I don't get an error, but the person isn't removed from the group either
DirContextOperations ctx = ldapTemplate.lookupContext(group.getDn());
IncrementalAttributesMapper<?> attributesMapper = new DefaultIncrementalAttributesMapper("member");
while (attributesMapper.hasMore()) {
String[] attributes = attributesMapper.getAttributesForLookup();
for (String attribute: attributes ) {
ldapTemplate.lookup(group.getDn(), attributesMapper.getAttributesForLookup(), attributesMapper);
ctx.removeAttributeValue(attribute, person.getDn() );
ldapTemplate.modifyAttributes(ctx);
}
}
Hopefully someone has had more success with this. Thanks in advance!
I've got the solution as posted
I was getting a malformed attribute error until I just realised that the BasicAttribute is expecting String parameters. I was incorrectly passing in a Name object to it.
ldapTemplate.modifyAttributes(group.getDn(), new ModificationItem[] {
new ModificationItem(
DirContext.REMOVE_ATTRIBUTE,
new BasicAttribute("member", person.getFullDn().toString() ))
});
Usually AD returns 'Objectsid' as a byte[]. So I type cast the value returned by AD in to byte[]. This procedure worked against several AD but not in one case. In this AD environment, I get following exception.
Exception: Unable to cast object of type 'System.String' to type 'System.Byte[]'. (System.InvalidCastException)
To debug this I started checking data-type of the value returned by AD, and it was system.string not byte[]. I printed this string and it was garbage. Then I passed this string to SecurityIdentifier() and I got exception again.
Exception: Value was invalid. Parameter name: sddlForm (System.ArgumentException)
Code:
//Using System.DirectoryServices.Protocols objects
object s = objSrEc[k1].Attributes[(string)obj3.Current][0];
string x = s.GetType().FullName;
if (x.ToLower() == "system.byte[]")
{
byte[] bSID = ((byte[])s);
if (bSID != null)
{
SecurityIdentifier SID = new SecurityIdentifier(bSID, 0);
String ObjectSID = SID.Value;
}
}
else if (x.ToLower() == "system.string")
{
SecurityIdentifier SID = new SecurityIdentifier((String)s); //ssdl excception
String ObjectSID = SID.Value;
}
This is the first time I am seeing AD return string data for ObjectSID. I have run my code against many AD servers. I am planning to check the data-type of ObjectSID in AD schema.
Do any one come across this behavior? Should I call the Win32 api ConvertByteToStringSid()?
Thanks
Ramesh
Sorry for reviving a graveyard post, but I had the same issue a year or so ago, managed to find out why and I figured I'd at least share the reason behind this behavior.
When using the System.DirectoryServices.Protocols namespace, all attribute values should be either a) a byte array, or b) a UTF-8 string. Thing is, the developers at Microsoft figured that they should help people by returning a string when the byte array returned from the underlying LDAP API can be formatted as one, and the byte array itself when the UTF-8 conversion fails. However, this is only true for the indexer of the DirectoryAttribute class, and not for the iterator (which always returns the byte array) or the GetValues method.
The safest way to always get a byte array when you want the SID is, as previously mentioned by others, the GetValues method.
I came through the same. Found this behavior normal when deal with ForeignSecurityPrincipals, however recently found this when translate attributes of built-in groups from some old Win 2K3 domains.
I don't like this as can't just ask the result attribute to tell me via GetType() what type are you and what should I do with you ( GetValues(Attribute.GetType()) ). One of the solutions was reading all attributes definition from AD schema, but this part might be a bit heavy (depends what you're looking for) although it was only a small part of overall AD processing the solution was performing.
Cheers,
Greg
I have the following objects: L1User, L2User, L3User (all inherits from User) and Document.
Every user can create the document but depending on the user type, the document will have a different status. So in case it's L1User, the document will be created with L1 status and so on:
Solution 1
Please note that after document is created, it will be saved in the database, so it should be natural to have a method create_document(User user) in Document object. In the method body I could check which type is the user and set manually appropriate status. Such approach seems rather not OOP to me.
Solution 2
Ok, so the next approach would be to have all users implement a common method (say create_document(Document doc)) which will set a status associated with the user and save the document in the database. My doubt here is that the document should be saved in it's own class, not the user.
Solution 3
So the final approach would similar to the above, except that the user will return modified document object to it's create_document(User user) method and save will be performed there. The definition of the method would be like this:
create_document(User user)
{
this = user.create_document(this);
this->save();
}
It also doesn't seems right to me...
Can anyone suggest a better approach?
I think that both Solutions 2 and 3 are ok from the OO point of view, since you are properly delegating the status assignment to the user object (contrary to solution 1, whare you are basically doing a switch based on the user type). Whether to choose 2 or 3 is more a matter of personal tastes.
However, I have a doubt: why do you pass a document to a create_document() method? I would go for a message name that best describes what it does. For example, in solution 3 (the one I like the most) I would go for:
Document>>create_document(User user)
{
this = user.create_document();
this->save();
}
and then
L1User>>create_document()
{
return new Document('L1');
}
or
Document>>create_document(User user)
{
this = new Document()
this = user.set_document_type(this);
this->save();
}
and then
L1User>>set_document_type(document)
{
document.setType('L1');
}
Edit: I kept thinking about this and there is actually a fourth solution. However the following approach works only if the status of a document doesn't change through its lifetime and you can map the DB field with a getter instead of a property. Since the document already knows the user and the status depends on the user, you can just delegate:
Document>>getStatus()
{
return this.user.getDocumentStatus();
}
HTH
I'm trying to find out the unboundid AttributeSyntax type for a specific attribute name and it's simply not working.
Here's the example test code that I'm using to achieve this:
#Test
public void testLDAPSchema() {
try {
LDAPConnection connection = new LDAPConnection();
connection.connect("hessmain", 389);
connection.bind("CN=Administrator,CN=Users,DC=FISHBOWL,DC=NET", "password");
Schema s = connection.getSchema();
System.out.println(s.toString());
AttributeTypeDefinition atd = s.getAttributeType("directReports");
Set<AttributeTypeDefinition> oat = s.getOperationalAttributeTypes();
Set<AttributeSyntaxDefinition> l = s.getAttributeSyntaxes();
AttributeSyntaxDefinition asd1 = s.getAttributeSyntax(atd.getOID());
AttributeSyntaxDefinition asd2 = s.getAttributeSyntax(atd.getSyntaxOID());
AttributeSyntaxDefinition asd3 = s.getAttributeSyntax(atd.getBaseSyntaxOID());
connection.close();
} catch (Exception e) {
Assert.fail(e.getMessage());
}
}
From the above code, all the sets are empty. This also means that no matter which OID I pass to the schema getAttributeSyntax method that I will simply get a null return.
Is there any reason why I can't get the attribute syntaxes from an Active Directory server schema?
Thanks
I don't think that this is specific to the UnboundID LDAP SDK for Java. I'm not sure that Active Directory exposes this information over LDAP. When I perform a general LDAP search to retrieve schema information, I can see the attributeTypes and objectClasses attributes, but ldapSyntaxes isn't returned (and in fact ldapSyntaxes doesn't appear in the list of attribute types).
Similarly, none of the attribute type definitions includes a USAGE element, which is what is used to indicate that the attribute type is operational (e.g., "USAGE directoryOperation").
It may well be that Active Directory simply doesn't report this information at all. It could be that it provides some other non-standard way to get this information (e.g., a control or extended operation, or some other entry that can be retrieved), but if there is then I don't know about it.