| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a nested group with ghost users is added, its ghost attribute should
propagate within the nested group structure much like the memberuid
attribute. Unlike the memberuid attribute, the ghost attribute is only
semi-managed by the memberof plugin and added manually to the original
entry.
This bug caused LDB errors saying that attribute or value already exists
when a group with a ghost user was added to the hierarchy as groups were
updated with an attribute they already had.
|
| | |
|
| |
|
|
|
|
|
| |
Large memberof delete operations can cause quite a number of searches
and the results are attached to a delop operation structure.
Make sure we free this payload once the operation is done and these
results are not used anymore so that we get a smaller total memory footprint.
|
| |
|
|
|
| |
We were skipping the check on the next value in the added list when a match
was found for the currentr value being checked.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Some assignments deleted, two return value inspections were
added.
Ticket: #589
|
| |
|
|
|
|
| |
With complex hierarchies it could happen that the group just deleted was
re-added by mistake to the list of groups a user is member of, causing the user
to have a stray memberof value in its entry.
|
|
|
Also update BUILD.txt
|
