[jira] Created: (COUCHDB-942) CouchDB build fails without eunit
CouchDB build fails without eunit - Key: COUCHDB-942 URL: https://issues.apache.org/jira/browse/COUCHDB-942 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1 Reporter: Robert Newson Assignee: Robert Newson A recent upgrade to mochiweb introduced a dependency on eunit but the build tools were not updated to match (mea culpa) This ticket includes a patch to mochiweb to make eunit completely optional (and declines to take the option). The patch has been submitted upstream (https://github.com/mochi/mochiweb/pull/22) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-942) CouchDB build fails without eunit
[ https://issues.apache.org/jira/browse/COUCHDB-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-942: -- Attachment: 0001-make-eunit-completely-optional.patch This patch applies against 54aa7e0 of mochiweb itself. A similar patch for couchdb's imported copy to follow. CouchDB build fails without eunit - Key: COUCHDB-942 URL: https://issues.apache.org/jira/browse/COUCHDB-942 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1 Reporter: Robert Newson Assignee: Robert Newson Attachments: 0001-make-eunit-completely-optional.patch A recent upgrade to mochiweb introduced a dependency on eunit but the build tools were not updated to match (mea culpa) This ticket includes a patch to mochiweb to make eunit completely optional (and declines to take the option). The patch has been submitted upstream (https://github.com/mochi/mochiweb/pull/22) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Access validation for docs and views
So I'm extending my proposal with this example:
Big company's people are stored in couchdb (200 - 400 people), with salary
field.
You may create views that will show total salary or salary of each
developers group, while not permitting to access individual salary.
My proposal: limiting views and docs separately.
2010/11/9 Fedor Indutny fedor.indu...@gmail.com
Yes, sorry it was not clear, but it's exactly like you're saying.
So my proposal is:
Add *validate_doc_view* function in _design documents with arguments like
*doc, userCtx, req*.
Add *validate_view_access* function into _design/views/view_name with
arguments like *req, userCtx*.
Example:
http://indutny.couchone.com/_utils/document.html?access_proposal/_design/test
(admin
party is here, so feel free to try anything).
So you can throw {forbidden: some text} in any of this callbacks, if user
have no access to item.
Also for views, you can limit access to specific range for user (like in
example).
2010/11/9 Bram Neijt bne...@gmail.com
I think I'm missing a part of this.
If you want a user to see only part of the document, would you not
create a view that only emits parts of the document?
I'm new at this, so could you write up an usage example for me?
Greets,
Bram
On Mon, Nov 8, 2010 at 5:34 PM, Fedor Indutny fedor.indu...@gmail.com
wrote:
Hi everyone!
You've discussed earlier possibility of adding access validators to
_design
documents, this feature it's a kind of thing that many couchdb users
will be
glad to see.
The conclusion of previous discussion was that we can't add this
validators,
because we actually won't be able to tell later, whether user can access
_design/view or not.
What if we could add *validate_view_**access *to _design document?
It's not only fix of problem, I've mentioned above, but also a feature:
You'll be able to allow user to access only view, without having an
access
to a full document.
So, for example, views could show only *title* field of document, while
*
price* field will be hidden in a document itself.
What do you think?
--
(Node.js, Ruby, Python, PHP developer)
Fedor Indutny
--
Fedor Indutny
--
Fedor Indutny
Re: Access validation for docs and views
I think we must discuss here, whether we can bypass this access limitation
or not.
If we can - this access limitation is useless, if not - we definitely must
review it and think about adding this to couchdb.
2010/11/9 Fedor Indutny fedor.indu...@gmail.com
So I'm extending my proposal with this example:
Big company's people are stored in couchdb (200 - 400 people), with
salary field.
You may create views that will show total salary or salary of each
developers group, while not permitting to access individual salary.
My proposal: limiting views and docs separately.
2010/11/9 Fedor Indutny fedor.indu...@gmail.com
Yes, sorry it was not clear, but it's exactly like you're saying.
So my proposal is:
Add *validate_doc_view* function in _design documents with arguments like
*doc, userCtx, req*.
Add *validate_view_access* function into _design/views/view_name with
arguments like *req, userCtx*.
Example:
http://indutny.couchone.com/_utils/document.html?access_proposal/_design/test
(admin
party is here, so feel free to try anything).
So you can throw {forbidden: some text} in any of this callbacks, if
user have no access to item.
Also for views, you can limit access to specific range for user (like in
example).
2010/11/9 Bram Neijt bne...@gmail.com
I think I'm missing a part of this.
If you want a user to see only part of the document, would you not
create a view that only emits parts of the document?
I'm new at this, so could you write up an usage example for me?
Greets,
Bram
On Mon, Nov 8, 2010 at 5:34 PM, Fedor Indutny fedor.indu...@gmail.com
wrote:
Hi everyone!
You've discussed earlier possibility of adding access validators to
_design
documents, this feature it's a kind of thing that many couchdb users
will be
glad to see.
The conclusion of previous discussion was that we can't add this
validators,
because we actually won't be able to tell later, whether user can
access
_design/view or not.
What if we could add *validate_view_**access *to _design document?
It's not only fix of problem, I've mentioned above, but also a feature:
You'll be able to allow user to access only view, without having an
access
to a full document.
So, for example, views could show only *title* field of document, while
*
price* field will be hidden in a document itself.
What do you think?
--
(Node.js, Ruby, Python, PHP developer)
Fedor Indutny
--
Fedor Indutny
--
Fedor Indutny
--
Fedor Indutny
Per document authorization wiki page
I would like to collect links and information related to per document authorization on the Wiki. http://wiki.apache.org/couchdb/PerDocumentAuthorization Could somebody create the above page and give me (BramNeijt) permission to edit it? Greets, Bram
[jira] Commented: (COUCHDB-674) Inconsistent error response, DELETE vs _bulk_docs deleted=true
[
https://issues.apache.org/jira/browse/COUCHDB-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930134#action_12930134
]
A. Bram Neijt commented on COUCHDB-674:
---
Wouldn't it be weird to get a can't find the document if you want to mark it
as deleted?
I mean, there is a difference between actually deleting it and updating it to a
deleted state. The first implies the object is there, the second implies the
object is in a deletable state.
I'm not convinced they should return the same error messages.
Inconsistent error response, DELETE vs _bulk_docs deleted=true
--
Key: COUCHDB-674
URL: https://issues.apache.org/jira/browse/COUCHDB-674
Project: CouchDB
Issue Type: Bug
Components: Database Core
Reporter: Matt Goodall
The result from deleting an already deleted document using an HTTP DELETE and
a _bulk_docs {deleted: true} is not consistent.
$ curl http://localhost:5984/scratch/foo -X PUT -d '{}'
{ok:true,id:foo,rev:1-967a00dff5e02add41819138abb3284d}
$ curl
http://localhost:5984/scratch/foo?rev=1-967a00dff5e02add41819138abb3284d -X
DELETE
{ok:true,id:foo,rev:2-eec205a9d413992850a6e32678485900}
$ curl
http://localhost:5984/scratch/foo?rev=1-967a00dff5e02add41819138abb3284d -X
DELETE
{error:not_found,reason:deleted}
$ curl http://localhost:5984/scratch/_bulk_docs -X POST -d '{docs: [{_id:
foo, _rev: 1-967a00dff5e02add41819138abb3284d, _deleted: true}]}'
[{id:foo,error:conflict,reason:Document update conflict.}]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-561) JSLint errors in jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930133#action_12930133 ] A. Bram Neijt commented on COUCHDB-561: --- I ran JSLint[1] and fixed some of the more obvious errors in https://github.com/bneijt/couchdb/commit/04e5890facf26d2e46ca5cec5c4ac1ee610d4830 Not all error where solved because they where things like var method which shadow global variables. JSLint errors in jquery.couch.js Key: COUCHDB-561 URL: https://issues.apache.org/jira/browse/COUCHDB-561 Project: CouchDB Issue Type: Improvement Reporter: Jan Kassens Attachments: jslintErrors.patch This patch fixes the jslint errors in jquery.couch.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-943) Reformat comments with type specs and @doc directives
[ https://issues.apache.org/jira/browse/COUCHDB-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930135#action_12930135 ] Adam Kocoloski commented on COUCHDB-943: Great patch Dale. This has been on my todo list for far too long. Reformat comments with type specs and @doc directives - Key: COUCHDB-943 URL: https://issues.apache.org/jira/browse/COUCHDB-943 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Priority: Minor Attachments: format_comments.patch Start introducing consistent use of @doc directives and type specifications, makes it easier to use dialyzer and ensures the comments show up in generated documentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-943) Reformat comments with type specs and @doc directives
Reformat comments with type specs and @doc directives - Key: COUCHDB-943 URL: https://issues.apache.org/jira/browse/COUCHDB-943 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Priority: Minor Attachments: format_comments.patch Start introducing consistent use of @doc directives and type specifications, makes it easier to use dialyzer and ensures the comments show up in generated documentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-943) Reformat comments with type specs and @doc directives
[ https://issues.apache.org/jira/browse/COUCHDB-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-943: Attachment: format_comments.patch Reformat comments with type specs and @doc directives - Key: COUCHDB-943 URL: https://issues.apache.org/jira/browse/COUCHDB-943 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Priority: Minor Attachments: format_comments.patch Start introducing consistent use of @doc directives and type specifications, makes it easier to use dialyzer and ensures the comments show up in generated documentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[
https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930114#action_12930114
]
Filipe Manana commented on COUCHDB-912:
---
Dale, looks a lot better now.
Only 3 things left:
1) For JavaScript code, the CouchDB convention is to use 2 spaces for each
indentation level. Also, the test should probably go into the design_docs.js
file. I don't think such a small test should go into a separate file (others
may disagree);
2) Besides validating the patch, don't you want to make sure the access is only
allowed for GET requests? Because like it is now, it seems to me that anonymous
users are allowed to add (PUT) attachments to the design doc;
3) The is_design_attachment function could still be left out, and instead have
do_db_req/2 like:
case {Anon, RestParts, Req#httpd.method} of
{true, [ _design, _DdocName, C:8, _/binary | _ ], 'GET'} when C =/=
$_ -
fun couch_db:open_int/2;
_ -
fun couch_db:open/2
end
This makes it simple and shorter imho.
Good work!
Anonymous Access to Design Docs on private DB's
---
Key: COUCHDB-912
URL: https://issues.apache.org/jira/browse/COUCHDB-912
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Reporter: Dale Harvey
Attachments: anon.patch, attachment_permissions.js
Right now people need to go through futon in order to login to couchapps
running on private databases, this is a pretty big limitation on the type of
couchapps that can be built
Propose adding the ability for users to flag the design docs as readable for
anonymous users, could be implemented though an attribute on the design doc?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
