Page MenuHomePhabricator

User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE
Closed, ResolvedPublic

Description

After finishing task T2393, when an author closes an audit, it stays in "Partially Audited" state.

Version: latest master version updated just now from GIT.
Reproduction: create a commit as user A. User A accepts this commit in audit. State is "Partially Audited".

Event Timeline

Can you describe how audit works in your organization and why you want authors to be able to close audits after T2393?

I'd like to find a workflow approach which doesn't require authors to audit or unilaterally close audit on their own commits.

Standard workflow is:

  • Herald adds a group of people responsible for the audit to every commit.
  • An Auditor picks several commits (he has to remove the group and add himself as Auditor, so no other auditors pick the same commit at the same time)
  • Then Auditor accepts a commit or raises a concern.
  • When the concern is raised, the Author prepares a new commit fixing this concern with commit message "Depends on ..."
  • Then the Author has to go to the Phabricator and change the state to "Needs Verification"; also he should assign this fixing commit to the same Auditor (unfortunately, I don't know how to do this automatically, via commit message or Herald).
  • Now the Auditor can see both commits and can accept them.

Sometimes, several good developers can accept their own commits (Author = Auditor:-)). We are satisfied with the global option "audit.can-author-close-audit", but currently it does not work. This means that an experienced Author with a very minor changes (e.g. message for user was changed) has to wait for someone to audit his code.

he has to remove the group and add himself as Auditor

You may be able to use Projects or Owners to create groups. Any member of a Project or Package auditor can accept on behalf of the project or package.

has to wait for someone to audit his code

Could he just remove all the auditors instead?

You could also add a condition like this to your rules which trigger audits:

[ Commit message ] [ does not contain ] [ "((minor))" ]

Then users could skip audit by adding the text "((minor))" to their commit messages when they make a minor change.

You may be able to use Projects or Owners to create groups. Any member of a Project or Package auditor can accept on behalf of the project or package.

Yes, right! Except the author :-)

Could he just remove all the auditors instead?

Good point. We will use this approach. What for is "audit.can-author-close-audit" then?

epriestley claimed this task.

What for is "audit.can-author-close-audit" then?

I'm hoping to just remove it now that we have "Needs Verification", but want to wait a little and see if there are remaining use cases that we aren't aware of. I suspect that removing auditors and "Needs Verification" may cover pretty much everything, and we may be able to remove this option soon.