On 02/11/2019 08:35 AM, William Brown wrote:
On 11 Feb 2019, at 17:01, Anuj Borah <abo...@redhat.com> wrote:
Hi,
As 'Entry' is not allowed to use now , In replace of Entry we are suggested to
use UserAccounts and UserAccount which is very limited to some object classes .
(['account','posixaccount','inetOrgPerson','organizationalPerson’]
)
There are many other types than this though?
src/lib389/lib389/plugins.py:23:class Plugin(DSLdapObject):
src/lib389/lib389/plugins.py:199:class MEPConfig(DSLdapObject):
src/lib389/lib389/plugins.py:233:class MEPTemplate(DSLdapObject):
src/lib389/lib389/plugins.py:444:class ReferentialIntegrityConfig(DSLdapObject):
src/lib389/lib389/plugins.py:758:class MemberOfSharedConfig(DSLdapObject):
src/lib389/lib389/plugins.py:887:class AutoMembershipRegexRule(DSLdapObject):
src/lib389/lib389/plugins.py:905:class AutoMembershipDefinition(DSLdapObject):
src/lib389/lib389/plugins.py:1015:class AutoMembershipRegexRule(DSLdapObject):
src/lib389/lib389/plugins.py:1120:class LinkedAttributesConfig(DSLdapObject):
src/lib389/lib389/plugins.py:1551:class AccountPolicyConfig(DSLdapObject):
src/lib389/lib389/plugins.py:1598:class DNAPluginConfig(DSLdapObject):
src/lib389/lib389/idm/organizationalrole.py:17:class
OrganizationalRole(DSLdapObject):
src/lib389/lib389/idm/nscontainer.py:11:class nsContainer(DSLdapObject):
src/lib389/lib389/idm/nscontainer.py:49:class nsHiddenContainer(DSLdapObject):
src/lib389/lib389/idm/domain.py:11:class Domain(DSLdapObject):
src/lib389/lib389/idm/posixgroup.py:18:class PosixGroup(DSLdapObject):
src/lib389/lib389/idm/organization.py:17:class Organization(DSLdapObject):
src/lib389/lib389/idm/ipadomain.py:11:class IpaDomain(DSLdapObject):
src/lib389/lib389/idm/group.py:17:class Group(DSLdapObject):
src/lib389/lib389/idm/group.py:104:class UniqueGroup(DSLdapObject):
src/lib389/lib389/idm/organizationalunit.py:16:class
OrganizationalUnit(DSLdapObject):
src/lib389/lib389/idm/account.py:15:class Account(DSLdapObject):
src/lib389/lib389/tombstone.py:18:class Tombstone(DSLdapObject):
src/lib389/lib389/backend.py:393:class Backend(DSLdapObject):
src/lib389/lib389/backend.py:831:class DatabaseConfig(DSLdapObject):
src/lib389/lib389/tasks.py:24:class Task(DSLdapObject):
src/lib389/lib389/pwpolicy.py:287:class PwPolicyEntry(DSLdapObject):
src/lib389/lib389/config.py:28:class Config(DSLdapObject):
src/lib389/lib389/config.py:205:class Encryption(DSLdapObject):
src/lib389/lib389/config.py:233:class RSA(DSLdapObject):
src/lib389/lib389/config.py:358:class LDBMConfig(DSLdapObject):
src/lib389/lib389/monitor.py:16:class Monitor(DSLdapObject):
src/lib389/lib389/monitor.py:109:class MonitorLDBM(DSLdapObject):
src/lib389/lib389/monitor.py:143:class MonitorBackend(DSLdapObject):
src/lib389/lib389/monitor.py:190:class MonitorChaining(DSLdapObject):
src/lib389/lib389/saslmap.py:12:class SaslMapping(DSLdapObject):
src/lib389/lib389/index.py:27:class Index(DSLdapObject):
src/lib389/lib389/index.py:64:class VLVSearch(DSLdapObject):
src/lib389/lib389/index.py:147:class VLVIndex(DSLdapObject):
src/lib389/lib389/encrypted_attributes.py:15:class EncryptedAttr(DSLdapObject):
src/lib389/lib389/_mapped_object.py:84:class DSLdapObject(DSLogging):
src/lib389/lib389/_mapped_object.py:441: if not issubclass(type(obj1),
DSLdapObject) or not issubclass(type(obj2), DSLdapObject):
src/lib389/lib389/_mapped_object.py:442: raise ValueError("Invalid
arguments: Expecting object types that inherits 'DSLdapObject' class")
src/lib389/lib389/agreement.py:23:class Agreement(DSLdapObject):
src/lib389/lib389/cos.py:18:class CosTemplate(DSLdapObject):
src/lib389/lib389/cos.py:65:class CosIndirectDefinition(DSLdapObject):
src/lib389/lib389/cos.py:111:class CosPointerDefinition(DSLdapObject):
src/lib389/lib389/replica.py:881:class Replica(DSLdapObject):
src/lib389/lib389/replica.py:1288:class
BootstrapReplicationManager(DSLdapObject):
src/lib389/lib389/mappingTree.py:381:class MappingTree(DSLdapObject):
src/lib389/lib389/chaining.py:18:class ChainingConfig(DSLdapObject):
src/lib389/lib389/chaining.py:59:class ChainingDefault(DSLdapObject):
src/lib389/lib389/chaining.py:81:class ChainingLink(DSLdapObject):
src/lib389/lib389/changelog.py:20:class Changelog5(DSLdapObject):
src/lib389/lib389/rootdse.py:15:class RootDSE(DSLdapObject):
src/lib389/lib389/referral.py:14:class Referral(DSLdapObject):
src/lib389/lib389/schema.py:71:class Schema(DSLdapObject):
At worst, you can always use a raw:
DSLdapObject(instance, dn)
to get “minimal” access to *anything* regardless of type. The entire value
proposition of lib389 is that we wrap *the most common and useful types*. Each
one of these sub-classes of DSLdapObject provides wrappers, helps, guides,
functions and more to interacting with nearly every aspect of the server.
This way we will be able to create any kind of entry whether it may be
user/role/sub suffix or anything .
I think this is already a solved problem, so I don’t think we really need this?
See above,
Agree. The universal entry is DSLdapObject. If you need a special type
create a class as listed by William above. In the class you can do
additional checks related to the types or have meaningful defaults.
Just to avoid adding a class for role is not a sufficient reason to
change all the other usages
Please let me know what other changes i have to do to make more sophisticated.
Regards
Anuj Borah
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
