From eschwartz at archlinux.org  Tue Dec 11 14:44:37 2018
From: eschwartz at archlinux.org (Eli Schwartz)
Date: Tue, 11 Dec 2018 09:44:37 -0500
Subject: [PATCH] add rpc v6: support multiple _by_ fields
In-Reply-To: <CAKZM9esfbTLyTb67JxPfowJ2ASk0WXeodj-yMd1pQhJ-OvmUdg@mail.gmail.com>
References: <152230098326.25318.11919775333759781073@typhoon>
 <20180601025055.6938-1-afg984@gmail.com>
 <CAKZM9et=i8U=HjQMXo++Q8Jdiji0J71XB4SSTd+W-YwYAMO0PQ@mail.gmail.com>
 <9353fcf2-e9de-ebd4-b304-86b9ea9cedcd@archlinux.org>
 <CAKZM9esfbTLyTb67JxPfowJ2ASk0WXeodj-yMd1pQhJ-OvmUdg@mail.gmail.com>
Message-ID: <e3519332-431d-833b-10d0-e17f39399cb0@archlinux.org>

On 11/6/18 2:07 AM, ??? wrote:
> Of course, v6 should absolutely support what is possible now in v5.
> The previous patch is more about asking if we can agree on the interface.
> I'll work on to bring the v6 patch up to date with the new rpc methods
> supported in v5.

Any update?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20181211/bd21de1f/attachment.asc>

From afg984 at gmail.com  Wed Dec 12 17:12:50 2018
From: afg984 at gmail.com (=?UTF-8?B?5bCk56uL5a6H?=)
Date: Thu, 13 Dec 2018 01:12:50 +0800
Subject: [PATCH] add rpc v6: support multiple _by_ fields
In-Reply-To: <e3519332-431d-833b-10d0-e17f39399cb0@archlinux.org>
References: <152230098326.25318.11919775333759781073@typhoon>
 <20180601025055.6938-1-afg984@gmail.com>
 <CAKZM9et=i8U=HjQMXo++Q8Jdiji0J71XB4SSTd+W-YwYAMO0PQ@mail.gmail.com>
 <9353fcf2-e9de-ebd4-b304-86b9ea9cedcd@archlinux.org>
 <CAKZM9esfbTLyTb67JxPfowJ2ASk0WXeodj-yMd1pQhJ-OvmUdg@mail.gmail.com>
 <e3519332-431d-833b-10d0-e17f39399cb0@archlinux.org>
Message-ID: <CAKZM9etQ+ffoS63QXsfmtj86Vw2XoRrSJ3qDE67fGN5pskXa2A@mail.gmail.com>

I'm a bit busy these days, but I think I can have a working patch
around the weekend

Eli Schwartz <eschwartz at archlinux.org> ? 2018?12?11? ?? ??10:44???
>
> On 11/6/18 2:07 AM, ??? wrote:
> > Of course, v6 should absolutely support what is possible now in v5.
> > The previous patch is more about asking if we can agree on the interface.
> > I'll work on to bring the v6 patch up to date with the new rpc methods
> > supported in v5.
>
> Any update?
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>

From jelle at vdwaa.nl  Thu Dec 20 19:36:15 2018
From: jelle at vdwaa.nl (Jelle van der Waa)
Date: Thu, 20 Dec 2018 20:36:15 +0100
Subject: [PATCH] web: remove unused $window_length
Message-ID: <20181220193615.16817-1-jelle@vdwaa.nl>

From: Jelle van der Waa <jelle at vdwaa.nl>

---
 web/lib/aurjson.class.php | 1 -
 1 file changed, 1 deletion(-)

diff --git a/web/lib/aurjson.class.php b/web/lib/aurjson.class.php
index c51e9c2..d0091f1 100644
--- a/web/lib/aurjson.class.php
+++ b/web/lib/aurjson.class.php
@@ -152,7 +152,6 @@ class AurJSON {
 			return false;
 		}
 
-		$window_length = config_get("ratelimit", "window_length");
 		$this->update_ratelimit($ip);
 		$stmt = $this->dbh->prepare("
 			SELECT Requests FROM ApiRateLimit
-- 
2.20.1

From johannes at kyriasis.com  Sun Dec 23 21:14:30 2018
From: johannes at kyriasis.com (=?UTF-8?q?Johannes=20L=C3=B6thberg?=)
Date: Sun, 23 Dec 2018 22:14:30 +0100
Subject: [PATCH] Make delete and merge links create an auto-accepted request
Message-ID: <20181223211430.18947-1-johannes@kyriasis.com>

This lets us have a better paper-trail over what happens in the AUR.

Signed-off-by: Johannes L?thberg <johannes at kyriasis.com>
---
 web/html/pkgbase.php        | 23 +++++++++++++----------
 web/lib/pkgreqfuncs.inc.php | 14 +++++++-------
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/web/html/pkgbase.php b/web/html/pkgbase.php
index 46ad77e..8efa51e 100644
--- a/web/html/pkgbase.php
+++ b/web/html/pkgbase.php
@@ -70,12 +70,10 @@ if (check_token()) {
 		list($ret, $output) = pkgbase_vote($ids, false);
 	} elseif (current_action("do_Delete")) {
 		if (isset($_POST['confirm'])) {
-			if (!isset($_POST['merge_Into']) || empty($_POST['merge_Into'])) {
-				list($ret, $output) = pkgbase_delete($ids, NULL, $via);
-				unset($_GET['ID']);
-				unset($base_id);
-			}
-			else {
+			$type = "deletion";
+			$merge_base_id = NULL;
+			if (isset($_POST['merge_Into']) && !empty($_POST['merge_Into'])) {
+				$type = "merge";
 				$merge_base_id = pkgbase_from_name($_POST['merge_Into']);
 				if (!$merge_base_id) {
 					$output = __("Cannot find package to merge votes and comments into.");
@@ -83,12 +81,17 @@ if (check_token()) {
 				} elseif (in_array($merge_base_id, $ids)) {
 					$output = __("Cannot merge a package base with itself.");
 					$ret = false;
-				} else {
+				}
+			}
+			if ($type == "deletion" || ($type == "merge" && $merge_base_id)) {
+				list($ret, $output, $request_id) = pkgreq_file($ids, $type, $_POST['merge_Into'],
+					"Trusted User-requested auto-accepted ".$type.".");
+				if ($ret) {
 					list($ret, $output) = pkgbase_delete($ids, $merge_base_id, $via);
-					unset($_GET['ID']);
-					unset($base_id);
 				}
 			}
+			unset($_GET['ID']);
+			unset($base_id);
 		}
 		else {
 			$output = __("The selected packages have not been deleted, check the confirmation checkbox.");
@@ -112,7 +115,7 @@ if (check_token()) {
 	} elseif (current_action("do_SetKeywords")) {
 		list($ret, $output) = pkgbase_set_keywords($base_id, preg_split("/[\s,;]+/", $_POST['keywords'], -1, PREG_SPLIT_NO_EMPTY));
 	} elseif (current_action("do_FileRequest")) {
-		list($ret, $output) = pkgreq_file($ids, $_POST['type'], $_POST['merge_into'], $_POST['comments']);
+		list($ret, $output, $_reqid) = pkgreq_file($ids, $_POST['type'], $_POST['merge_into'], $_POST['comments']);
 	} elseif (current_action("do_CloseRequest")) {
 		list($ret, $output) = pkgreq_close($_POST['reqid'], $_POST['reason'], $_POST['comments']);
 	} elseif (current_action("do_EditComaintainers")) {
diff --git a/web/lib/pkgreqfuncs.inc.php b/web/lib/pkgreqfuncs.inc.php
index 774ebe7..a15f101 100644
--- a/web/lib/pkgreqfuncs.inc.php
+++ b/web/lib/pkgreqfuncs.inc.php
@@ -124,19 +124,19 @@ function pkgreq_get_creator_email($id) {
  */
 function pkgreq_file($ids, $type, $merge_into, $comments) {
 	if (!has_credential(CRED_PKGREQ_FILE)) {
-		return array(false, __("You must be logged in to file package requests."));
+		return array(false, __("You must be logged in to file package requests."), NULL);
 	}
 
 	if (!empty($merge_into) && !preg_match("/^[a-z0-9][a-z0-9\.+_-]*$/D", $merge_into)) {
-		return array(false, __("Invalid name: only lowercase letters are allowed."));
+		return array(false, __("Invalid name: only lowercase letters are allowed."), NULL);
 	}
 
 	if (!empty($merge_into) && !pkgbase_from_name($merge_into)) {
-		return array(false, __("Cannot find package to merge votes and comments into."));
+		return array(false, __("Cannot find package to merge votes and comments into."), NULL);
 	}
 
 	if (empty($comments)) {
-		return array(false, __("The comment field must not be empty."));
+		return array(false, __("The comment field must not be empty."), NULL);
 	}
 
 	$dbh = DB::connect();
@@ -147,7 +147,7 @@ function pkgreq_file($ids, $type, $merge_into, $comments) {
 	$pkgbase_name = pkgbase_name_from_id($base_id);
 
 	if ($merge_into == $pkgbase_name) {
-		return array(false, __("Cannot merge a package base with itself."));
+		return array(false, __("Cannot merge a package base with itself."), NULL);
 	}
 
 	$q = "SELECT ID FROM RequestTypes WHERE Name = " . $dbh->quote($type);
@@ -155,7 +155,7 @@ function pkgreq_file($ids, $type, $merge_into, $comments) {
 	if ($row = $result->fetch(PDO::FETCH_ASSOC)) {
 		$type_id = $row['ID'];
 	} else {
-		return array(false, __("Invalid request type."));
+		return array(false, __("Invalid request type."), NULL);
 	}
 
 	$q = "INSERT INTO PackageRequests ";
@@ -208,7 +208,7 @@ function pkgreq_file($ids, $type, $merge_into, $comments) {
 		pkgbase_delete(array($base_id), NULL, NULL, true);
 	}
 
-	return array(true, __("Added request successfully."));
+	return array(true, __("Added request successfully."), $request_id);
 }
 
 /**
-- 
2.20.1

From eschwartz at archlinux.org  Sun Dec 23 21:58:03 2018
From: eschwartz at archlinux.org (Eli Schwartz)
Date: Sun, 23 Dec 2018 16:58:03 -0500
Subject: [PATCH] Make delete and merge links create an auto-accepted
 request
In-Reply-To: <20181223211430.18947-1-johannes@kyriasis.com>
References: <20181223211430.18947-1-johannes@kyriasis.com>
Message-ID: <00e03d0f-cfa9-0c39-ac58-ca8d2bf562a0@archlinux.org>

On 12/23/18 4:14 PM, Johannes L?thberg wrote:
> This lets us have a better paper-trail over what happens in the AUR.
I'm opposed to this change.

The purpose of those links is arguably to do things in exceptional
circumstances. There are cases where an auto-accepted request is simply
uninteresting information. e.g., the following cases:

- user submits deletion request, Eli Schwartz uses "close" instead of
  "accept", with the message "merged instead". Do we really need
  additional notifications here?

- deletion of spam packages

Moreover, the current proposal is simply inferior in every possible way
compared to simply submitting a request, then accepting it. That way you
get to leave a message saying why it happened... I would simply never
ever use the delete/merge links if I actually wanted to send out
notifications.

On top of this, where is the notification for orphaning packages against
the will of the maintainer?

...

It's basically accepted practice regardless that when TUs adopt a
package into community, they submit a deletion request and then accept
it. This will traditionally include the high-content comment "moved to
community".

The current patchset was proposed in response to one TU on IRC, who
feels strongly about the goal of said paper trail and desired to have
the entire feature removed from aurweb altogether. I propose instead
that we follow my recommendation to document on the wiki at
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines that
TUs should submit a deletion request *with the relevant comment* rather
than deleting the package.

I see no reason to modify the emergency override tools. I'm unaware of
the lack of a paper trail being a significant issue. Perhaps we should
just trust each TU in good faith that the reason we elected them is
because they're not going to misuse the tools?

Note: regarding the person who suggested on IRC that the links should be
removed, the orphan link in particular is utterly crucial to remain,
since aurweb includes a feature to accept an orphan request early by
leaving a comment and *not* actually orphaning the package. This
requires the TU to manually use the orphan link. If orphan requests were
given fair treatment with the other two request types, this would result
in a second notification every time it was used.
More generally, if you wish to leave a comment in the acceptance
notification, you must use the same comment form followed by manual
followup when closing a deletion or merge request as well (although
those are not locked for the duration of a 14-day grace period).

...

tl;dr this is a documentation problem, not a code problem. It is also
not a practical problem, since we're supposedly already doing the
preferred method... right?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20181223/4ab2358d/attachment.asc>

From eschwartz at archlinux.org  Sun Dec 23 23:04:40 2018
From: eschwartz at archlinux.org (Eli Schwartz)
Date: Sun, 23 Dec 2018 18:04:40 -0500
Subject: [PATCH] Make delete and merge links create an auto-accepted
 request
In-Reply-To: <1545602673.brks68jpgw.astroid@hydrogen.kyriasis.com.none>
References: <20181223211430.18947-1-johannes@kyriasis.com>
 <00e03d0f-cfa9-0c39-ac58-ca8d2bf562a0@archlinux.org>
 <1545602673.brks68jpgw.astroid@hydrogen.kyriasis.com.none>
Message-ID: <e43edbfc-aad6-b365-cbb3-84df618d4869@archlinux.org>

This accidentally did not get CC'ed to the list... I've inlined my response.

On 12/23/18 5:19 PM, Johannes L?thberg wrote:
> Excerpts from Eli Schwartz's message of December 23, 2018 22:58:
>> On 12/23/18 4:14 PM, Johannes L?thberg wrote:
>>> This lets us have a better paper-trail over what happens in the AUR.
>> I'm opposed to this change.
>>
>> The purpose of those links is arguably to do things in exceptional
>> circumstances. There are cases where an auto-accepted request is simply
>> uninteresting information. e.g., the following cases:
>>
>> - user submits deletion request, Eli Schwartz uses "close" instead of
>>   "accept", with the message "merged instead". Do we really need
>>   additional notifications here?
>>
> 
> I think that is a better portrayal of reality, yes.  I do not see there 
> being any really justified reasons for anyone being able to delete a 
> package without a request.

There was a request. :p

>> - deletion of spam packages
>>
> 
> I believe that that is still just as interesting to have in the history.
> 
> We've already had quite a few cases where there was confusion as to what 
> happened to a package just because it was deleted directly.

Eh, not sure I really agree that spam is interesting.

>> Moreover, the current proposal is simply inferior in every possible way
>> compared to simply submitting a request, then accepting it. That way you
>> get to leave a message saying why it happened... I would simply never
>> ever use the delete/merge links if I actually wanted to send out
>> notifications.
>>
> 
> It's hardly inferior, it's just different.  There are obviously TUs that 
> currently use them but don't want to leave a message, this still lets 
> them do exactly that.  And even if we would not actually create an 
> auto-accepted request for it, I believe that it is wrong to not always 
> send out at least a notification when a package is deleted.  Having an 
> actual request created just makes it easier to see them along with all 
> other changes.

I'd much prefer to see the ability to include a comment on the direct
action interface then. :D

I don't believe that would make it mandatory to leave a comment -- it
would just give one the option to.

>> On top of this, where is the notification for orphaning packages against
>> the will of the maintainer?
>>
> 
> That is fundamentally a different change and feature that has nothing to 
> do with this patch.

I see it as the same change/feature, adding a paper trail to to
request-like actions. Could you clarify why you see it as different?

>> It's basically accepted practice regardless that when TUs adopt a
>> package into community, they submit a deletion request and then accept
>> it. This will traditionally include the high-content comment "moved to
>> community".
>>
> 
> Sure.  Except for when they don't.
> 
>> The current patchset was proposed in response to one TU on IRC,
> 
> Incorrect.  I have been planning on doing this for months, and talked to 
> Lukas about it months ago as well.

Sorry for jumping to conclusions. :( All I saw was today's mention on IRC.

>> who feels strongly about the goal of said paper trail and desired to have
>> the entire feature removed from aurweb altogether. I propose instead
>> that we follow my recommendation to document on the wiki at
>> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines that
>> TUs should submit a deletion request *with the relevant comment* rather
>> than deleting the package.
>>
>> I see no reason to modify the emergency override tools.
> 
> Before you get to call them "emergency override tools" we're going to 
> both need to *clearly* label them as such, and preferably move them to a 
> separate section.  As it is they are, and will continue to be, "just 
> tools," especially since they are the easiest option for performing 
> these actions.

Fair point, although I do rather consider them as such I guess this is
not really clear. Especially since I still don't want to use them
without a comment box...

(I would like to see more tools, "just" or otherwise, since in some ways
the TU interface is rather rough. Deleting comments one by one is still
the only way to deal with the repeated essay writing/gaming sites/MS
Word spam too.)

>> Note: regarding the person who suggested on IRC that the links should be
>> removed, the orphan link in particular is utterly crucial to remain,
>> since aurweb includes a feature to accept an orphan request early by
>> leaving a comment and *not* actually orphaning the package. This
>> requires the TU to manually use the orphan link. If orphan requests were
>> given fair treatment with the other two request types, this would result
>> in a second notification every time it was used.
>> More generally, if you wish to leave a comment in the acceptance
>> notification, you must use the same comment form followed by manual
>> followup when closing a deletion or merge request as well (although
>> those are not locked for the duration of a 14-day grace period).
>>
> 
> But then again, there is no reason to actually implement it that 
> simplistically either.

Okay. I think, as I said above, that the current available tools are a
bit primitive in how they expose functionality regardless.

Maybe there is some way we could revamp all this in the process? Maybe
if we exposed the comment box in the "delete/merge/orphan this package"
landing page, we could unify comments and notifications across all three
action paths? (request-accept, request-close, and direct action links)

Rather than submitting an auto-accepted request, we'd simply prompt for
an optional comment, then perform the final notification (and if "via"
is passed, do so using pkgreq_close, else just use notify).

This would also mean we only send out one email, instead of two.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20181223/3af81a18/attachment.asc>

From eschwartz at archlinux.org  Sun Dec 23 23:10:42 2018
From: eschwartz at archlinux.org (Eli Schwartz)
Date: Sun, 23 Dec 2018 18:10:42 -0500
Subject: Fwd: [PATCH] Make delete and merge links create an auto-accepted
 request
In-Reply-To: <1545602673.brks68jpgw.astroid@hydrogen.kyriasis.com.none>
References: <1545602673.brks68jpgw.astroid@hydrogen.kyriasis.com.none>
Message-ID: <a8d713a7-28e3-6d98-d473-14339d960035@archlinux.org>

Plain copy of reply

-------- Forwarded Message --------
Subject: Re: [PATCH] Make delete and merge links create an auto-accepted
request
Date: Sun, 23 Dec 2018 23:19:47 +0100
From: Johannes L?thberg <johannes at kyriasis.com>
To: Eli Schwartz <eschwartz at archlinux.org>

Excerpts from Eli Schwartz's message of December 23, 2018 22:58:
> On 12/23/18 4:14 PM, Johannes L?thberg wrote:
>> This lets us have a better paper-trail over what happens in the AUR.
> I'm opposed to this change.
> 
> The purpose of those links is arguably to do things in exceptional
> circumstances. There are cases where an auto-accepted request is simply
> uninteresting information. e.g., the following cases:
> 
> - user submits deletion request, Eli Schwartz uses "close" instead of
>   "accept", with the message "merged instead". Do we really need
>   additional notifications here?
> 

I think that is a better portrayal of reality, yes.  I do not see there
being any really justified reasons for anyone being able to delete a
package without a request.

> - deletion of spam packages
> 

I believe that that is still just as interesting to have in the history.

We've already had quite a few cases where there was confusion as to what
happened to a package just because it was deleted directly.

> Moreover, the current proposal is simply inferior in every possible way
> compared to simply submitting a request, then accepting it. That way you
> get to leave a message saying why it happened... I would simply never
> ever use the delete/merge links if I actually wanted to send out
> notifications.
> 

It's hardly inferior, it's just different.  There are obviously TUs that
currently use them but don't want to leave a message, this still lets
them do exactly that.  And even if we would not actually create an
auto-accepted request for it, I believe that it is wrong to not always
send out at least a notification when a package is deleted.  Having an
actual request created just makes it easier to see them along with all
other changes.

> On top of this, where is the notification for orphaning packages against
> the will of the maintainer?
> 

That is fundamentally a different change and feature that has nothing to
do with this patch.

> 
> It's basically accepted practice regardless that when TUs adopt a
> package into community, they submit a deletion request and then accept
> it. This will traditionally include the high-content comment "moved to
> community".
> 

Sure.  Except for when they don't.

> The current patchset was proposed in response to one TU on IRC,

Incorrect.  I have been planning on doing this for months, and talked to
Lukas about it months ago as well.

> who feels strongly about the goal of said paper trail and desired to have
> the entire feature removed from aurweb altogether. I propose instead
> that we follow my recommendation to document on the wiki at
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines that
> TUs should submit a deletion request *with the relevant comment* rather
> than deleting the package.
> 
> I see no reason to modify the emergency override tools.

Before you get to call them "emergency override tools" we're going to
both need to *clearly* label them as such, and preferably move them to a
separate section.  As it is they are, and will continue to be, "just
tools," especially since they are the easiest option for performing
these actions.

> Note: regarding the person who suggested on IRC that the links should be
> removed, the orphan link in particular is utterly crucial to remain,
> since aurweb includes a feature to accept an orphan request early by
> leaving a comment and *not* actually orphaning the package. This
> requires the TU to manually use the orphan link. If orphan requests were
> given fair treatment with the other two request types, this would result
> in a second notification every time it was used.
> More generally, if you wish to leave a comment in the acceptance
> notification, you must use the same comment form followed by manual
> followup when closing a deletion or merge request as well (although
> those are not locked for the duration of a 14-day grace period).
> 

But then again, there is no reason to actually implement it that
simplistically either.
-- 
Sincerely,
  Johannes L?thberg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20181223/e8c5b924/attachment-0001.asc>