[jira] Commented: (COUCHDB-1089) Let anonymous users access _active_tasks for view generation estimates
[ https://issues.apache.org/jira/browse/COUCHDB-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006106#comment-13006106 ] Dale Harvey commented on COUCHDB-1089: -- Caolan, do you mean expose the filter options on the (remote) target db that you are replicating too? I can see where that can be handy but I do think it sounds dangerous. Kowsik, if require_valid_user does what I think it does then it wont be affected, a private install will stay private. Filipe, the futon replication page is ok enough as a db admins tool, we are talking about providing a ui to replication for end users of applications built with couch (more specifically in my case, couchapps), right now its impossible for me to have continuous replication for my mobile apps because the user the app runs as is not an admin, I can start continous replication tasks but cant inspect whether they are running or not. > Let anonymous users access _active_tasks for view generation estimates > -- > > Key: COUCHDB-1089 > URL: https://issues.apache.org/jira/browse/COUCHDB-1089 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface, JavaScript View Server >Reporter: max ogden >Priority: Minor > Labels: http, view > Original Estimate: 3h > Remaining Estimate: 3h > > Currently you have to be a database administrator to access _active_tasks. > For UX purposes I would like to allow anyone to see view generation statuses, > preferably on a per database level. This solves the problem of the first user > to generate a view that then receives no time estimate as to when their > process will be completed. I can't think of an application use case for > making replication data public. > I spoke with Volker Mische about the implementation details on this issue and > he asserted after a code dive that it appears achievable, though the innards > of the view status code were not familiar to him. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COUCHDB-1088) Validate replication documents added to the replicator database
[ https://issues.apache.org/jira/browse/COUCHDB-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1088. Resolution: Fixed Fix Version/s: 1.2 1.1 Applied to trunk and branch 1.1.x. > Validate replication documents added to the replicator database > --- > > Key: COUCHDB-1088 > URL: https://issues.apache.org/jira/browse/COUCHDB-1088 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 1.1 >Reporter: Filipe Manana >Assignee: Filipe Manana > Fix For: 1.1, 1.2 > > Attachments: COUCHDB-1088.patch > > > Currently we don't validate the replication documents added to the replicator > database - we don't check if mandatory fields (source and target) are present > and if they have the right type (string or object). We also don't check if > optional fields, like "continuous" or "create_target", have the right type - > for example, often users specify the string "true" as the value for those 2 > fields when it should be a boolean. > The following patch adds some basic validation to the _replicator database > default document validation function. Besides throwing meaningful error > messages to the user, it also adds nice information in the log like for e.g.: > [info] [<0.3938.0>] OS Process #Port<0.35369> Log :: Error writing document > `rep1' to the replicator database: The `source' property must exist and be > either a string or an object. > [info] [<0.3887.0>] 127.0.0.1 - - PUT /test_suite_rep_db/rep1 403 > [info] [<0.3938.0>] OS Process #Port<0.35369> Log :: Error writing document > `rep1' to the replicator database: The `continuous' field must be a boolean. > [info] [<0.3887.0>] 127.0.0.1 - - PUT /test_suite_rep_db/rep1 403 > [info] [<0.3938.0>] OS Process #Port<0.35369> Log :: Error writing document > `rep1' to the replicator database: The `filter' field must be a non-empty > string. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COUCHDB-1085) Make the replication manager restart replications that end up in an error state
[ https://issues.apache.org/jira/browse/COUCHDB-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1085. Resolution: Fixed Applied to trunk. > Make the replication manager restart replications that end up in an error > state > --- > > Key: COUCHDB-1085 > URL: https://issues.apache.org/jira/browse/COUCHDB-1085 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 1.1 >Reporter: Filipe Manana >Assignee: Filipe Manana > Fix For: 1.2 > > Attachments: COUCHDB-1085.patch > > > So far, the replication manager tries up to 10 times (defined by the .ini > parameter "max_replication_retry_count") to start a replication. After it is > successfully started, if it ends up in an error state, it doesn't retry the > replication. > The following patch changes the replication manager's behaviour so that it > restarts replications that reach an error state (up to > "max_replication_retry_count" times). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-1089) Let anonymous users access _active_tasks for view generation estimates
[ https://issues.apache.org/jira/browse/COUCHDB-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006055#comment-13006055 ] Filipe Manana commented on COUCHDB-1089: I don't think you'll need to expose the filter and parameters for a replication anywhere. That is available in the replication documents that are stored in the replicator database (version 1.1 and onwards), just read the document and you get those fields in it. Also, being like a regular database, you can set its _security object to whatever fits your application. As for the UI, isn't the standard Futon database page enough? > Let anonymous users access _active_tasks for view generation estimates > -- > > Key: COUCHDB-1089 > URL: https://issues.apache.org/jira/browse/COUCHDB-1089 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface, JavaScript View Server >Reporter: max ogden >Priority: Minor > Labels: http, view > Original Estimate: 3h > Remaining Estimate: 3h > > Currently you have to be a database administrator to access _active_tasks. > For UX purposes I would like to allow anyone to see view generation statuses, > preferably on a per database level. This solves the problem of the first user > to generate a view that then receives no time estimate as to when their > process will be completed. I can't think of an application use case for > making replication data public. > I spoke with Volker Mische about the implementation details on this issue and > he asserted after a code dive that it appears achievable, though the innards > of the view status code were not familiar to him. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-1089) Let anonymous users access _active_tasks for view generation estimates
[ https://issues.apache.org/jira/browse/COUCHDB-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006024#comment-13006024 ] Caolan McMahon commented on COUCHDB-1089: - @Dale: if you find support for that patch I'd also consider exposing the filter and its parameters if a filter is used for replication. It could open up some really nice UI possiblities. Providing these details could make setting up custom sync with couchapps a user rather than an admin thing. Also, if we decide to expose _active_tasks on a per-database level it would make sense to expose it at the root level under a vhost (much like /_session). > Let anonymous users access _active_tasks for view generation estimates > -- > > Key: COUCHDB-1089 > URL: https://issues.apache.org/jira/browse/COUCHDB-1089 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface, JavaScript View Server >Reporter: max ogden >Priority: Minor > Labels: http, view > Original Estimate: 3h > Remaining Estimate: 3h > > Currently you have to be a database administrator to access _active_tasks. > For UX purposes I would like to allow anyone to see view generation statuses, > preferably on a per database level. This solves the problem of the first user > to generate a view that then receives no time estimate as to when their > process will be completed. I can't think of an application use case for > making replication data public. > I spoke with Volker Mische about the implementation details on this issue and > he asserted after a code dive that it appears achievable, though the innards > of the view status code were not familiar to him. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
