Fixed with rZd3a94fb23936865dd68b0abe3c886d5ab3289779

@petersen
i can't reprduce the bug at all. I tried

Fixed with a7247819577b294c89dae616f171ce003268a1aa

can reproduce.

All the tests which are in the iRony repository used to run through without errors. So if that changed on Winterfell, it should be looked at.

I didn't hear about such requirement. I create diffs only for things I'm not sure about.

Why is this not in a differential?

I recently run iRony's tests on Kolab Winterfell, and it gave me 14 failed tests. It looks like we don't really use these for CI, are we?

Account switching still doesn't properly update the view...

So, as I understand, it's better to integrate this with the invoicing process. It will be slower, because it will need to touch every user record. Now it fetches only the account-owner-user from ldap and if there's no changes in SQL database skips account users processing. Now it would need to fetch all users ldap records + SELECT their subscriptions to detect and apply changes. At least I can implement this in a way it won't need to fetch/SELECT twice per user.

Current code assumes that user has permissions to modify specified attributes.

Also, adding the TYPE attribute in v3 seems a reasonable change to me.

Yes, Apple clients also use "b" when exporting and synching contact photos although they can handle upper-cased values as well. But the way to go definitely is lower-cased.

In T1124#16709, @machniak wrote:

Ok, I'm almost there. Last thing is to get $base_dn and $root_dn. I suppose for $root_dn we'll just add configuration option. I'm not sure how to resolve $base_dn.

Ok, I'm almost there. Last thing is to get $base_dn and $root_dn. I suppose for $root_dn we'll just add configuration option. I'm not sure how to resolve $base_dn.

In T1125#16657, @machniak wrote:

In T1125#16655, @vanmeeuwen wrote:

I would consider syncing up the #HKCCP local database copy of what subscriptions an account may have held at some point in the past is probably the most sustainable solution.

I'm afraid a separate cronjob still puts some probably-out-of-date database in the lead, whereas LDAP must be.

Well, yes. Until the cronjob do the sync.

In T1125#16655, @vanmeeuwen wrote:

I would consider syncing up the #HKCCP local database copy of what subscriptions an account may have held at some point in the past is probably the most sustainable solution.

I'm afraid a separate cronjob still puts some probably-out-of-date database in the lead, whereas LDAP must be.

In T1125#16653, @machniak wrote:

1. It could be resolved in the invoicing routine, but on a higher level than subscriptions() method. However, I think that a separate cronjob would be better. Less chances we'll break something else ;)

1. It could be resolved in the invoicing routine, but on a higher level than subscriptions() method. However, I think that a separate cronjob would be better. Less chances we'll break something else ;)

In T1125#16619, @machniak wrote:

The "problem" is with "when it is time to generate the invoice". So, should we first detect if profile changed in ldap and create an invoice then or we should not and wait with hkccp subscriptions update until the new period starts or there's any other reason to create a new invoice? I suppose, we should detect changes and force new invoice.

In T1124#16618, @machniak wrote:

Only account type switch, shouldn't we allow a separate quota size selection?

Needs to wait till Wendsday, before continuing. KDE Applications 16.04 will branch off and the split is too much just two days before the dependency freeze.

The "problem" is with "when it is time to generate the invoice". So, should we first detect if profile changed in ldap and create an invoice then or we should not and wait with hkccp subscriptions update until the new period starts or there's any other reason to create a new invoice? I suppose, we should detect changes and force new invoice.

Only account type switch, shouldn't we allow a separate quota size selection?
Where to put this, in Settings > Preferences > Server Settings?