LDAP User Cleanup
background job for user clean up
adjust user backend for clean up
register background job
remove dead code
dependency injection
make Helper non-static for proper testing
check whether it is OK to run clean up job. Do not forget to pass arguments.
use correct method to get the config from server
methods can be private, proper indirect testing is given
no automatic user deletion
make limit readable for test purposes
make method less complex
add first tests
let preferences accept limit and offset for getUsersForValue
DI via constructor does not work for background jobs
after detecting, now we have retrieving deleted users and their details
we need this method to be public for now
finalize export method, add missing getter
clean up namespaces and get rid of unnecessary files
helper is not static anymore
cleanup according to scrutinizer
add cli tool to show deleted users
uses are necessary after recent namespace change
also remove user from mappings table on deletion
add occ command to delete users
fix use statement
improve output
big fixes / improvements
PHP doc
return true in userExists early for cleaning up deleted users
bump version
control state and interval with one config.php setting, now ldapUserCleanupInterval. 0 will disable it. enabled by default.
improve doc
rename cli method to be consistent with others
introduce ldapUserCleanupInterval in sample config
don't show last login as unix epoche start when no login happend
less log output
consistent namespace for OfflineUser
rename GarbageCollector to DeletedUsersIndex and move it to user subdir
fix unit tests
add tests for deleteUser
more test adjustements
Conflicts:
apps/user_ldap/ajax/clearMappings.php
apps/user_ldap/appinfo/app.php
apps/user_ldap/lib/access.php
apps/user_ldap/lib/helper.php
apps/user_ldap/tests/helper.php
core/register_command.php
lib/private/preferences.php
lib/private/user.php
add ldap:check-user to check user existance on the fly
Conflicts:
apps/user_ldap/lib/helper.php
forgotten file
PHPdoc fixes, no code change
and don't forget to adjust tests
Workaround required for IIS setups running ownCloud to prevent dataloss.
Long-term solution would be to move some configuration settings to the database
This commit will make the supported DBs for installation configurable within config.php. By default the following databases are tested: "sqlite", "mysql", "pgsql". The reason behind this is that there might be instances where we want to prevent SQLite to be used by mistake.
To test this play around with the new configuration parameter "supportedDatabases".
Correctly use overwritemailurl value when generating absolute urls in CLI
Fix#11500
Rename the config to *cli
Add overwrite.cli.url to the sample config
Revert separator fix, fixes unit test
* use ' instead of " for config option
* place default parameters where useful into sample
* use proper comment block
* limit line size to 80 characters
Remove the second comment which could be confused with suggesting an invalid value: `// 100 MiB`.
To keep the easily readable example value, it has been moved into the comment header for the config item.
This adds some security utilities to core including:
- A library for basic crypto operations (e.g. to encrypt passwords)
- A better library for cryptographic actions which allows you to specify the charset
- A library for secure string comparisions
Remove .htaccess
Remove .htaccess
Fix typo
Add public API
Use timing constant comparision
Remove CBC constant
Adjust code
Remove confusing $this
Hopefully this will stop people from copying the sample config. I'm so annoyed by all those wrong bug reports...
Add some explanation about this switch
Move check to init
* Use "filesystem_cache_readonly" config setting, update comment in config.sample
* Use $this->cacheActive to cache config setting
* Add public Scanner::setCacheActive() to set $cacheActive programmatically
Some people believe that they should copy the sample config to the "real" config. I noticed this several times in IRC and on the bugtracker.
I guess this warning should be enough to avoid this in the future.
Users often ask in IRC or the forum how to add another domain.
Hopefully they will be able to find it out on their own if we have an example with two domains.
It isn't uncommon that admins create a backup file of the config (i.e. `config.php.bak`) before performing any changes. This would allow everybody to read the backup of the configuration file which contain several secret and critical values.
I don't believe this is worth a backport or getting added to the installer. It's just a nice to have. People that create public readable backups of their configuration are the one to blame, not us :-)
When using an external cache folder, it is automatically mounted in
FileSystem::initFileSystem so that any app can use it transparently
by creating a view on the "/$user/cache" directory.
Add support for multiple memcached servers.
* owncloud/memcached-multiple-servers:
Readd support for memcached_server config variable.
Add support for multiple memcached servers.
