Skip to content

Commit

Permalink
Merge remote-tracking branch 'refs/remotes/origin/master'
Browse files Browse the repository at this point in the history
  • Loading branch information
skublik committed Oct 6, 2023
2 parents 4dec066 + 78e742d commit 1b52e7b
Show file tree
Hide file tree
Showing 3 changed files with 99 additions and 13 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -7,17 +7,10 @@
package com.evolveum.midpoint.gui.api.component.autocomplete;

import java.time.Duration;
import java.util.Collection;
import java.util.Iterator;

import com.evolveum.midpoint.gui.api.page.PageAdminLTE;
import com.evolveum.midpoint.gui.api.util.WebComponentUtil;
import com.evolveum.midpoint.gui.api.util.WebModelServiceUtils;
import com.evolveum.midpoint.prism.PrismObject;
import com.evolveum.midpoint.schema.GetOperationOptions;
import com.evolveum.midpoint.schema.SelectorOptions;
import com.evolveum.midpoint.schema.result.OperationResult;

import com.evolveum.midpoint.task.api.Task;

import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.attributes.AjaxRequestAttributes;
Expand Down Expand Up @@ -137,7 +130,8 @@ protected LookupTableType getLookupTable() {

protected LookupTableType getLookupTable() {
if (lookupTableOid != null) {
return WebComponentUtil.loadLookupTable(lookupTableOid, getPageBase());
PageAdminLTE parentPage = WebComponentUtil.getPage(AutoCompleteTextPanel.this, PageAdminLTE.class);
return WebComponentUtil.loadLookupTable(lookupTableOid, parentPage);
}
return null;
}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4024,13 +4024,13 @@ public static boolean isDarkModeEnabled() {
return session.getSessionStorage().getMode() == SessionStorage.Mode.DARK;
}

public static LookupTableType loadLookupTable(String lookupTableOid, PageBase pageBase) {
Task task = pageBase.createSimpleTask("Load lookup table");
public static LookupTableType loadLookupTable(String lookupTableOid, PageAdminLTE parentPage) {
Task task = parentPage.createSimpleTask("Load lookup table");
OperationResult result = task.getResult();
Collection<SelectorOptions<GetOperationOptions>> options = WebModelServiceUtils
.createLookupTableRetrieveOptions(pageBase.getSchemaService());
.createLookupTableRetrieveOptions(parentPage.getSchemaService());
PrismObject<LookupTableType> prismLookupTable =
WebModelServiceUtils.loadObject(LookupTableType.class, lookupTableOid, options, pageBase, task, result);
WebModelServiceUtils.loadObject(LookupTableType.class, lookupTableOid, options, parentPage, task, result);
if (prismLookupTable != null) {
return prismLookupTable.asObjectable();
}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4214,6 +4214,36 @@
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="purpose" type="tns:ShadowPurposeType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Purpose for existence (or non-existence) of a resource object referenced by the shadow.
E.g. it specifies whether the resource object is fully operational, whether it is not completely prepared yet,
it may indicate why we are keeping the resource object instead of deleting it, and so on.
It can be thought of as a "business lifecycle", specifying the reason for this object or shadow.

This information is maintained by midPoint, it is not directly projected to the resource.
This information supplements the resource object data, it keeps additional information that the resource does not have.
It is different from shadowLifecycleState, as shadowLifecycleState specifies the technical state in which resource object is
(e.g. not created yet, not deleted yet).
On the other hand, purpose represents the business information, the reason or intention that we have with the object.
For example, "incomplete" purpose describes an account that is technically in a perfect shape, technically fully operation,
yet user is not able to use that account yet.

This is also different from the regular lifecycleState.
The lifecycleState of a shadow is meant to be reflected directly to resource object.
E.g. lifecycleState of a shadow should be taken from lifecycle state of account, from one of its attributes
(similarly to administrativeStatus).
On the other hand, "purpose" is an information kept only by midPoint, not directly synchronized to the resource.
The "purpose" will work for all resources, regardless of whether they support lifecycle state (and its fidelity),
activation or any other details.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>ShadowType.purpose</a:displayName>
<a:since>4.8</a:since>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="dead" type="xsd:boolean" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Expand Down Expand Up @@ -4656,6 +4686,68 @@
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="ShadowPurposeType">
<xsd:annotation>
<xsd:documentation>
Purpose for existence (or non-existence) of a resource object referenced by the shadow.
E.g. it specifies whether the resource object is fully operational, whether it is not completely prepared yet,
it may indicate why we are keeping the resource object instead of deleting it, and so on.
It can be thought of as a "business lifecycle", specifying the reason for this object or shadow.

Purposes considered to the future:

* reserved: Resource object exists for the sole purpose of reserving identifiers or other resources.
E.g. account that exists only to make sure the username is not taken by any other account, or that a username is not re-used.
It can be used both for existing and non-existing resource objects.
I.e. it may be only a shadow, reserving identifier at midPoint level,
or it may be an account (probably inactive), reserving identifier at resource level.
May also be used for (non-existent or disabled) accounts that are yet to be "claimed" by the user.
(Question: do we need separate "thombstone" state for accounts that were deleted?)

* suspended: Resource object is inactivated (disabled) for a longer period of time.
E.g. used for maternal leave or sabbatical.
This purpose may be used to avoid deleting such accounts, e.g. in delayed delete scenarios.

* lingering: Resource object is still there, even though it should be gone already.
E.g. account exists (although it is disabled), even though it should be deleted.
This can be used to mark shadows that are kept due to disable-instead-of-delete scenarios.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="regular">
<xsd:annotation>
<xsd:documentation>
Regular, completely ordinary resource object.
It is in full working condition, everything works normally.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="REGULAR"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="incomplete">
<xsd:annotation>
<xsd:documentation>
Resource object is not complete, it is not yet fully usable.
Some kind of action is necessary to complete the process.

May be used for shadows that are technically in perfect working conditions, however user is not able to fully use them.
For example, an account that was created with random password, the password was not delivered to the user.
The user is expected to "activate" the account by resetting the password.
However, technically, the account is in perfect working condition, enabled, password is set and so on.
This "purpose" value is stored by midPoint to remember that additional action is needed to make this account fully operation on user level.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="INCOMPLETE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="ShadowAttributesType">
<xsd:annotation>
<xsd:documentation>
Expand Down

0 comments on commit 1b52e7b

Please sign in to comment.