We have decided to de-emphasize this “capability” as CouchDB doesn’t
guarantee old revisions to be around post compaction and in 2.x we
recommend compaction to run frequently (Cloudant runs it continuously),
so you’re less likely to be able to navigate old doc revision bodies.
Best
Jan
—
> On 29. Sep 2017, at 09:15, max <maxima...@gmail.com> wrote:
>
> Last question about 2.1, in fauxton I couldn't find a way to navigate
> through document revisions (like the '' previous version '' button in
> 1.6.1). Is it still possible ?
>
> Le 25 sept. 2017 2:59 PM, "Jan Lehnardt" <m...@jan.io> a écrit :
>
>> Ah gotcha! Thanks for clarifying :)
>>
>> Cheers
>> Jan
>> --
>>
>>> On 25. Sep 2017, at 14:42, Stefan du Fresne <ste...@medicmobile.org>
>> wrote:
>>>
>>> Apologies, I didn't mean to not use the _users system, I was referring
>> to the editing the permissions security properties of the _users DB in an
>> attempt to allow a non-admin user to make edits to that DB.
>>>
>>>> On 25 Sep 2017, at 11:31, Jan Lehnardt <j...@apache.org> wrote:
>>>>
>>>> Stefan is correct that this is expected behaviour, but I’d reject the
>> notion that
>>>> it is in any way recommended to not use the CouchDB user system. All
>> you need to
>>>> do is have a CouchDB admin user do the _users edits.
>>>>
>>>> Of course you can build your own system on top, but I wouldn’t
>> recommend that.
>>>>
>>>> Best
>>>> Jan
>>>> --
>>>>
>>>>> On 23. Sep 2017, at 15:17, max <maxima...@gmail.com> wrote:
>>>>>
>>>>> Thank you for your answers I'll try with simple web services layer.
>>>>>
>>>>> Le 23 sept. 2017 3:14 PM, "Stefan du Fresne" <ste...@medicmobile.org>
>> a
>>>>> écrit :
>>>>>
>>>>>> None that I know of no. Ideally it would just work, but I think
>> editing
>>>>>> permissions for _users is effectively deprecated at this point.
>>>>>>
>>>>>> Really the only thing you can do is write a security layer yourself,
>>>>>> either by wrapping CouchDB and converting those calls (after checking
>> your
>>>>>> own security) to be done by an admin user, or provide a separate API
>> etc.
>>>>>>
>>>>>> Stefan
>>>>>>> On 23 Sep 2017, at 13:40, max <maxima...@gmail.com> wrote:
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Any workaround from configuration ? I would like to avoid making
>> more
>>>>>>> couchdb admin...
>>>>>>>
>>>>>>> Le 23 sept. 2017 1:08 PM, "Stefan du Fresne" <ste...@medicmobile.org>
>> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> This is currently how it works yeah.
>>>>>>>>
>>>>>>>> I believe the current recommendation for user management is to
>>>>>> effectively
>>>>>>>> ignore the permissions matrix in the _users database and instead
>> wrap
>>>>>>>> CouchDB in your own permissions management.
>>>>>>>>
>>>>>>>> Stefan
>>>>>>>>> On 22 Sep 2017, at 17:36, max <maxima...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm trying CouchDB 2.1 and facing an (strange?) issue. I have given
>>>>>>>>> admin access through "Permissions" to "user1" and every user with
>> the
>>>>>>>>> role "manager". This allowed these users to call view from _design
>> in
>>>>>>>>> _users database. But this is not enough to delete other users, to
>> do
>>>>>>>>> that user have to be a super CouchDB Admin. Is this the expected
>>>>>>>>> behavior? I got "Only admins may delete other user docs" whereas
>> he is
>>>>>>>>> admin.
>>>>>>>>>
>>>>>>>>> This is my _users database permissions:
>>>>>>>>>
>>>>>>>>> {"error":"unauthorized","reason":"Authentication
>>>>>>>>> required.","admins":{"names":["user1"],"roles":["manager"]}}
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Max.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Professional Support for Apache CouchDB:
>>>> https://neighbourhood.ie/couchdb-support/
>>>>
>>>
>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
