Trying to do something with OpenLDAP that should be very simple, just can't seem to find a clear answer. I need to be able to organize any person's contact attributes according to their "type". For example, email would be type 6. So, if I wanted to send an email to all members of my OU, I would choose those that have a type 6 address.
since LDAP attributes are a name, value pair, I don't see how to assign an additional property to a contact address, yet it seems like a common enough problem. Any suggestions?
Attributes in the directory server model are indeed name [optional option] value constructs. To accomplish the task you describe, you could assign another attribute to the entry. RFC2798 defines the employeeType (link) attribute type with a syntax of DirectoryString and an equality matching rule of caseIgnoreMatch. Perhaps this attribute could be used for your purposes. If you assigned the attribute like:
employeeType: type 6
the LDAP client would then find all those employees with a filter like
(&(employeeType=type 6)(objectClass=inetOrgPerson)).
If you had concerns about the matching being caseIgnoreMatch you could specify that the server use caseExactMatch by using an extensible match filter like:
(&(employeeType:caseExactMatch:=type 6)(objectClass=inetOrgPerson))
employeeType is multi-valued, therefore, employees could have more than one employeeType. Any value that is a valid DirectoryString could be assigned to employeeType.
Related
In Workorder tracking , there is a field "LEAD" which will display ID of lead.
In our requirement we have to display Leadname along with Lead ID.
SO I created a new field for Leadname in Workorder and used crossover domain with a new relation between Wordorder and Person. Relation where clause being personid=:lead
The crossover domain copies over the value of Leadname from Displayname attribute of PERSON object and is working fine when we give an ID in Lead attribute of Workorder.
However in case if I give a Lead ID and then remove the lead ID in WO , then leadname still remains It doesnt get modified to null.
I believe its because the crossover condition (personid=:lead ) is not satisfied and hence no action is being performed. I tried setting condition on Source and Destination as well but that also is not working.
Is there any way to default a field to null in case if crossover where clause condition is not met.
I was able to get this implemented by using automation script , but would like to know whether same can be achieved by some other means.
If it is just displaying the information you should use a multipart textbox to show lead and displayname of the person. You need to add a relation from workorder to person using the lead attribute. Then normal Maximo logic will clear the 'description' when you clear the actual lead field.
There is a way to cross-over fixed values, including null, to clear another field on a crossover action. Just make an ALNDOMAIN with a empty value (leave description empty) In the crossover domain use a relation that points to this specific domain/value and use dot-notation to crossover the description. Use relationname.description as the sourcefield in your crossover
RFE 72680 / crossovers, option to set targets to null or default value when trigger field becomes null is intended to address this shortfall in functionality. Please cast your vote!
According to the help pop up:
ID
This field's value represents the script ID, used to identify this
record for scripting purposes. It is a text field.
Internal ID
This field's value is a read-only system-generated unique identifier.
It is an integer field.
Both fields seem to uniquely identity a record type.
One is a string, one a integer.
The string ID is used for searches and
loading of records, but I've also seen Internal ID used when
referring to a record type from a lists point of view.
Can anyone provide the reasoning behind having two identifiers and when to use one versus the other when scripting?
The major difference is that you (as the creator of a custom record or script) are in complete control of the text ID. You can establish patterns and best practices for defining these IDs, and it will make it very easy for developers to identify record types just by looking at the string ID. You have no control over the numeric ID. When looking at code, it is much easier for me to determine what records I am referring to if it looks like:
nlapiSearchRecord('customrecord_product', null, filters, columns);
nlapiResolveURL('SUITELET', 'customscript_sl_orderservice', 'customdeploy_sl_orderservice')
as opposed to looking at:
nlapiSearchRecord(118, null, filters, columns);
nlapiResolveURL('SUITELET', 13, 1)
I'm not even sure the second nlapiSearchRecord actually works, but I know that nlapiResolveURL can be written that way.
That said, if you simply let NetSuite generate the text ID, you'll end up with generic IDs like customrecord1, which I find no more useful than the numeric ID. It is a good practice to explicitly specify your own IDs.
Furthermore, the numeric ID can vary between environments (e.g. Sandbox could be different than Production, until a subsequent refresh occurs). If you are following good migration practices, then the text ID should never vary between environments, so your code would not have to make any kind of decision on which ID to use based on environment.
Rarely have I found myself referencing any record, whether native or custom, by its numeric ID; scripts are always using the text ID to reference a record type.
I have a resource called "Item" having the following fields :
Id
Name
Description
I want the user to be able to Get Items from the database whether by specifying the id or name.
eg, if I have this entry in the database : (1,House, this is a House) corresponding to (id,name,description), then if the user send a Get request specifying that
id=1
or
name="table"
this should return the entry : (1,Table, this is a table).
The question is, can I do this in restlet ?
can I have the router routing /Item/{itemId} and /Item/{itemName} routed to the same ItemResource class ? in this case, should I have two implementations for the getrepresentation function ?
You can route /Item/{itemId} and /Item/{itemName} to the same resource class, but as the commenter wrote (nearly a year ago!), you run the risk of ambiguity if the id and name namespaces aren't disjoint. A better design would be to have two resources:
/Item?name=MyName
/Item/1234
The first of these would be search resource that returns all items with name MyName. The second would simply look up the unique item 1234.
You could implement this with one resource class, but it would look neater as two separate resource classes (possibly with a common abstract superclass).
I'm new to XML and XSD and I have a question about XML-Schema validation. Consider XML file:
<RequestList>
<Request1 id="1">...</Request1>
<Request2 id="2">...</Request2>
.
.
.
</RequestList>
I want to force id attribute to be unique. Google helped me much in case that elements have the same type. But I can't make a sequence of sinlge element 'Request', because each request can contain different information, according to his type. What should I do?
Thanks in advance for help.
The XML spec defines a unique ID type:
Validity constraint: ID
Values of type ID must match the Name
production. A name must not appear
more than once in an XML document as a
value of this type; i.e., ID values
must uniquely identify the elements
which bear them.
The Name production is
[5] Name ::= (Letter | '_' | ':') ( NameChar)*
This says that if an attribute is declared as of type ID (whether in DTD or XMLSchema) then the validator must ensure that it is unique within the document. Note that the ID must start with a letter or underscore so pure numbers won't work.
Personally I don't use ID (I find it too limiting for me) but you should probably consider it. Note that XML Schema tools will not by default generate unique IDs for you (although XSLT will).
Note that the name of the attribute (in your case "id") can be any valid name (e.g. "Id", "foo") but it must be declared in the DTD or Schema as of type ID.
UPDATE: OP asks why we don't use XML ID. We frequently merge nodes from different sources , e.g.
and
The IDs are whatver the authors have chosen (this is not a single database app - think more of people creating blogposts in a community and creating their ids. So it's common for people to create the same ID (mainly m1). In that case we might well have:
This looks horrid but there are no easy answers.
We use other information to disambiguate. We have a rule that ids are unique within a certain scope - e.g. that the atoms within a molecule must have unique IDs.
If we used a unique ID generator these are completely opaque and the humans in our community would rebel (they did).
IDs are not easy to manage in an unmanaged human community!
I’ll keep it short and sweet. Does anyone really know what the "ListTemplateOwner" tag of the elements.xml's "Receivers" node really means?
From Microsoft’s site: http://msdn.microsoft.com/en-us/library/ms431081(loband).aspx
ListTemplateOwner: Optional Text. Specifies the GUID of the list template owner if the list template is registered via Features, or the name of the site definition if the list template is registered by a site definition.
If the list is defined by a ListTemplate in a Feature then ListTemplateOwner is the ID of the feature that defined the list.
When you're refering to any of the standard lists (with ListTemplateId < 10000) then you don't need to specify a ListTemplateOwner (due to backwards compability)
When you're refering to a list that's defined by you or a third party, then you need the combination of ListTemplateId (> 10000 and matching the Type attribute from the defining ListTemplate) and ListTemplateOwner matching the FeatureId of the feature that defined the ListTemplate.
This is due to the fact that when you define a ListTemplate the rule is that Type should be > 10000 and unique inside the feature, but any number of feature may have their own ListTemplate with type 10001 (and feature which define lists usually just start from 10001)
If the list is defined by a ListTemplate in a Site definition then ListTemplateOwner is the name of that Site Definition, but don't define lists in Site definitions do it in features.
This is not correct, the feature ID when set to the current feature, which contains the list definition for the list type, does not target the reciever correctly...
<ListTemplate
Name="SomeList"
Type="99002"
BaseType="0"
OnQuickLaunch="TRUE"
SecurityBits="11"
Sequence="410"
DisplayName="Some List"
Description="Custom List used for whatnot"
Image="/_layouts/images/itgen.gif"/>
<Receivers ListTemplateId="99002" ListTemplateOwner="B1E4631D-52A1-48d0-A319-2DDC2893AA57">
What you need to do is give each List Template a unique ID, regardless of the owning feature.
I am guessing that it refers to the ID (GUID) of the SharePoint object that owns the list template. Think of it like the ID column of a database and this would be it's foreign key.