We were using stretchr/testify and test-go/testify inconsitently and
sometimes mixed in the same tests. This can cause very strange issue,
e.g when using things like mock.MatchedBy().
This moves all our code to stretchr/testify, which seems to be far
more active and maintained then test-go/testify.
* enhancement: use reva client pool selectors
register mock service to registry and pass tests
* enhancement: bump reva
* Fix a couple of linter issues
---------
Co-authored-by: Ralf Haferkamp <rhaferkamp@owncloud.com>
The "calling function XYZ" log messages should only appear at debug level.
Message indicating client errors when creating a user (e.g. invalid characters
in username or missing attributes) are logged at info level (instead of debug)
now.
The old default ttl of 30 minutes for the caches seems way too long. It
could cause outdated information users or groups to be returned for
quite a while. Especially since the TTL was reset every time an entry was
fetched from the cache. This is disabled now as well.
Fixes: #6320
* Streamline the store implementation with and into reva
* Adapt to the cache/store refactoring in reva
* Streamline config options and their env vars
* Apply suggestions from code review
Co-authored-by: Martin <github@diemattels.at>
* Use the same database for all stores
* Bump reva
* Configure stat and filemetadata cache separately
* Fix default config
---------
Co-authored-by: Martin <github@diemattels.at>
* api test to get personal drive information of other users
* fix the broken personal drive listing
* removed scenario from expected failure after issue fixed
---------
Co-authored-by: Michael Barz <mbarz@owncloud.com>
As some setups don't have email addresses setup or reuse email
addresses, the keycloak search has to be done by username as that
is guaranteed to always be unique and defined.
This PR changes that.
By setting GRAPH_LDAP_GROUP_CREATE_BASE_DN a distinct subtree can be
configured where new LDAP groups are created. That subtree needs to be
subordinate to GRAPH_LDAP_GROUP_BASE_DN. All groups outside for
GRAPH_LDAP_GROUP_CREATE_BASE_DN are considered read-only and only groups
below that DN can be updated and deleted.
This is introduced for a pretty specific usecase where most groups are managed
in an external source (e.g. a read-only replica of an LDAP tree). But we still
want to allow the local administrator to create groups in a writeable subtree
attached to that replica.
* api test for user trying to set their own personal space quota
* removed duplicate scenarios for set quota
* updated expected scenario
* fix wrong status code
* updated expected failure scenario after wrong status code fix
---------
Co-authored-by: Michael Barz <mbarz@owncloud.com>
Ralf Haferkamp