Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Marko Käning]

On 13 May 2016, at 18:58 , Warren Young  wrote:
> We aren’t talking about fossil ui.  We’re talking about
> 
>  $ f ci -m “closes [12345abc]”

+1
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Ron W]

On Fri, May 13, 2016 at 4:02 PM, Warren Young  wrote:

> Again, I don’t see why you’d want to spend a lot of effort expanding TH1
> to support this.  That requires every Fossil user to rebuild Fossil with
> TH1 hook support and install the custom hook.  This should be built into
> the core of Fossil.
>

Control over what actions via "business logic" in the hook script.


> It’s becoming a violation of expectation here in 2016 that this *doesn’t*
> happen.


If Fossil had, like many other VCSs, the capability to spawn external
programs as hooks, this would have been implemented in those hooks long ago
- the same way many other VCSs do it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Warren Young]

On May 13, 2016, at 1:16 PM, Ron W  wrote:
> 
> I did not claim my scheme would work for a remote Fossil server.

The HTTP server provided by “fossil ui” is still “remote” as far as my 
questions go.  

The point is, the command line fossil client making the ci call probably didn’t 
keep the cookie it was given when it originally did the clone, and it may not 
be able to manufacture it afterward.  I did some poking around, and the 
returned cookie looks like a secure token to me, rather than something the 
client side could assemble at will.

But it turns out that it is not necessary to make the edit via HTTP.  A bit of 
playing around shows that if you close (or otherwise modify) a ticket in your 
local clone of the repo, Fossil attempts to sync the change to the remote.

You could do this before the checkin and have the ticket modification be 
autosync’d to the server, but that feels like a premature optimization.  It 
might be better to hold off modifying the local tickets until after the remote 
server accepts the checkin, then do another autosync.  More expensive, but also 
more correct.

If you don’t have permission to change the remote tickets, Fossil complains:

  Error: not authorized to write

I don’t see that as a real problem.  IMHO, it’s fine if a checkin claims to 
close a given ticket without making the checkin acceptance conditional on the 
ticket actually closing.  Someone else with the necessary permissions can later 
manually close it; you’d be no worse off than today.

> Ideally, the set of commands available to TH1 hook scripts could be expanded 
> to include things like adding/updating tags and updating tickets.

Again, I don’t see why you’d want to spend a lot of effort expanding TH1 to 
support this.  That requires every Fossil user to rebuild Fossil with TH1 hook 
support and install the custom hook.  This should be built into the core of 
Fossil.

It’s becoming a violation of expectation here in 2016 that this *doesn’t* 
happen.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Ron W]

On Fri, May 13, 2016 at 12:58 PM, Warren Young  wrote:
>
> We aren’t talking about fossil ui.  We’re talking about
>
>   $ f ci -m “closes [12345abc]”
>
> Under your scheme, that would run a TH1 commit hook.  So: does an HTTP
> call made from fossil ci send a suitable cookie to tell the remote fossil
> server on autosync that it is user foo, so it should let it close ticket
> [12345abc]?


I did not claim my scheme would work for a remote Fossil server.

I've only been answering your questions as you've made them.

Ideally, the set of commands available to TH1 hook scripts could be
expanded to include things like adding/updating tags and updating tickets.
Alternately, the capability to spawn a program (or a shell to run a script).

Maybe those things can be done (mostly) in SQL via TH1's query command, but
doing so would require crafting code to create various artifacts to be
inserted into the blob table. I don't know how dificult that would be.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Warren Young]

On May 13, 2016, at 10:45 AM, Ron W  wrote:
> 
> > Without that cookie, fossil server doesn’t know that fossil client is 
> > logged in.
> 
> When the Fossil server is started with "fossil ui path/to/repo &”

We aren’t talking about fossil ui.  We’re talking about

  $ f ci -m “closes [12345abc]”

Under your scheme, that would run a TH1 commit hook.  So: does an HTTP call 
made from fossil ci send a suitable cookie to tell the remote fossil server on 
autosync that it is user foo, so it should let it close ticket [12345abc]?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Ron W]

On Fri, May 13, 2016 at 11:45 AM, Warren Young  wrote:

> On May 12, 2016, at 5:38 PM, Ron W  wrote:
> > The update would be to the same repo as the commit, so the URL would be "
> http://localhost:8080/tktedit; so credentials would not be needed.
>
> Credential lookup is cookie-based.  If I make an HTTP query through TH1
> back to the same server, will Fossil provide that cookie?  If not, then the
> remote Fossil will reject the request since it’s effectively coming in as
> anonymous.
>
> Without that cookie, fossil server doesn’t know that fossil client is
> logged in.


When the Fossil server is started with "fossil ui path/to/repo &", Fossil
(a) accepts only connections from localhost, and (b) assumes the user who
started the server is the is the user making the ticket update (or other
web UI operation).

(This behavior of Fossil can be disabled, but is the "out of the box"
default.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Warren Young]

On May 12, 2016, at 5:38 PM, Ron W  wrote:
> 
> On Thu, May 12, 2016 at 5:14 PM, Warren Young  wrote:
> Where would it get the user credentials for that?  Modifying tickets is not 
> allowed for anonymous.
> 
> The update would be to the same repo as the commit, so the URL would be 
> "http://localhost:8080/tktedit; so credentials would not be needed.

Credential lookup is cookie-based.  If I make an HTTP query through TH1 back to 
the same server, will Fossil provide that cookie?  If not, then the remote 
Fossil will reject the request since it’s effectively coming in as anonymous.

Without that cookie, fossil server doesn’t know that fossil client is logged in.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Ron W]

On Thu, May 12, 2016 at 5:14 PM, Warren Young  wrote:
>
> Where would it get the user credentials for that?  Modifying tickets is
> not allowed for anonymous.
>

The update would be to the same repo as the commit, so the URL would be "
http://localhost:8080/tktedit; so credentials would not be needed.


> Thus, TH1 hooks might be a good way to prototype the behavior of this
> feature prior to implementing it, but in the end, we’d want something in
> the core that works everywhere, out of the box.


Even with explicit support in the core, still makes sense for the commit
hook to control the ticket updating. "Close ticket on commit" is only one
of several possible (sets of) actions. (Where I work, for example, possible
next states would be "Reviewing" and "Validation".)

> TH1 also has a query command that runs an SQL expression.
>
> That would be a valid argument for prototyping the feature in TH1: if the
> C implementation will involve some intricate SQL, it might be nice to
> prototype it in an interpreted language that doesn’t require rebuilding
> Fossil for each attempt.


I looked at tkt,c. The SQL is assembled field by field, but doesn't look
particularly complex. Once the ticket and ticketchng tables are updated,
might be able to use a SELECT expression to help create the Ticket Change
artifact. Then it can be inserted into the blob table. (Fossil's core,
however, creates the change artifact first, then updates the ticket and
ticketchng tables from it.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Warren Young]

On May 12, 2016, at 2:07 PM, Ron W  wrote:
> 
> On Wed, May 11, 2016 at 7:29 PM, Warren Young  wrote:
> On May 11, 2016, at 3:57 PM, Marko Käning  wrote:
> >
> > An auto-closing of tickets if the commit comment contains stg like "closed 
> > [TICKETID]", "closes [TICKETID]", "fixed [TICKETID]", "fixes [TICKETID]", 
> > would be nice.
> 
> it might be possible to do this with a TH1 commit hook script. TH1 has a http 
> command, so you can build an HTTP post request to trigger a web service.

Where would it get the user credentials for that?  Modifying tickets is not 
allowed for anonymous.

No, you’d have to call one of the internal Fossil APIs exported by Fossil, so 
that it would use the committer’s credentials.

> I've never used Fossil's TH1 hooks, so I don't know much about them.

The main thing to know about them is that they aren’t enabled by default, and 
you have to write their code manually.  That makes them good for things that 
are entirely site-specific.

Thus, TH1 hooks might be a good way to prototype the behavior of this feature 
prior to implementing it, but in the end, we’d want something in the core that 
works everywhere, out of the box.

I don’t really see a need to prototype it, though, because this is a fairly 
common thing in other VCS + bug tracker integrations.  The fact that Fossil has 
both in the same package but doesn’t have this typical behavior built in is 
what surprises so many.

> TH1 also has a query command that runs an SQL expression.

That would be a valid argument for prototyping the feature in TH1: if the C 
implementation will involve some intricate SQL, it might be nice to prototype 
it in an interpreted language that doesn’t require rebuilding Fossil for each 
attempt.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Ron W]

On Wed, May 11, 2016 at 7:29 PM, Warren Young  wrote:

> On May 11, 2016, at 3:57 PM, Marko Käning 
> wrote:
> >
> > An auto-closing of tickets if the commit comment contains stg like
> "closed [TICKETID]", "closes [TICKETID]", "fixed [TICKETID]", "fixes
> [TICKETID]", would be nice.
>
> Agreed.  The only problem is the perennial one: Someone has to do it.  Are
> you “someone?”  :)


For what it's worth, it might be possible to do this with a TH1 commit hook
script. TH1 has a http command, so you can build an HTTP post request to
trigger a web service. If that service is a Fossil server serving your
repository, might be possible to update tickets in the repository.

I've never used Fossil's TH1 hooks, so I don't know much about them.

TH1 also has a query command that runs an SQL expression. However, in
Fossil, updating a ticket involves creating Ticket Change artifacts, not
just changing things in an SQL table, so this command could only be used to
read ticket info as SQL updates do not also create change artifacts.

(Basically, Fossil's use of SQL is (1) an index engine to find repository
artifacts, (2) a meta data store, and (3) a cache of a subset of the
information stored in artifacts. (The artifacts are stored as blobs in the
blob table.))
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature request: auto-closing of tickets a la Trac

[Warren Young]

On May 11, 2016, at 3:57 PM, Marko Käning  wrote:
> 
> An auto-closing of tickets if the commit comment contains stg like "closed 
> [TICKETID]", "closes [TICKETID]", "fixed [TICKETID]", "fixes [TICKETID]", 
> would be nice.

Agreed.  The only problem is the perennial one: Someone has to do it.  Are you 
“someone?”  :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users