[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fossil-users
Subject:    Re: [fossil-users] Shared Logins
From:       Clark Christensen <cdcmicro () yahoo ! com>
Date:       2010-02-12 0:29:53
Message-ID: 322411.76637.qm () web31809 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

Hi Kees,

I understand the issues, and how sessions work.  And I understand all the reasons why \
not to use a shared login.  I've argued them from the other side, too :-)

In this case, what I needed was a quick & dirty, temporary, inside-the-firewall issue \
tracker where a small developer group, and a dozen or two testers could interact in \
the final phase before QA.  Fossil filled the bill admirably.  Since I have been \
using it for my own code projects for 5 or 6 months, it was a snap to set-up, and \
customize.

So, now that I understand it's by design, not being able to use a shared login is \
only a small, soon to be forgotten nit.

I'm a Perl and Javascript guy.  I'd love to be able to modify the source and \
contribute back.  I just don't have the time to learn C enough to make a difference.

 -Clark



----- Original Message ----
From: Kees Nuyt <k.nuyt@zonnet.nl>
To: fossil-users@lists.fossil-scm.org
Sent: Thu, February 11, 2010 12:05:44 PM
Subject: Re: [fossil-users] Shared Logins

On Thu, 11 Feb 2010 11:21:28 -0800 (PST), Clark wrote:

> I'm using Fossil (2009-12-18 build) as a simple
> intranet-based issue tracker for a project at
> my company.  The plan was to let the end-users
> log-in as anonymous to create/view tickets,
> and create a different login for the developers
> to share so they can manage/assign/classify
> the tickets.
> 
> No prob for the anonymous users.
> 
> But the developers started complaining about
> having to log-in all the time.  It's clear
> their sessions were invalidated each time
> another developer logged in. Is this by design?

Yes, the idea is that a userid identifies a user, and a
login identifies a session for the specific user.

> I created individual logins for the developers
> as a workaround, but  I'd like to not have to
> do that.  Any suggestions?

My suggestion: Don't do it. If you insist, be prepared to
take the consequences. You'll never know who contributed to
which tickets. In my opinion an issue tracker should track
that info. In an ITIL audit, it shows you're "in control".

But yes, you can do it. Fossil is open source, you are
welcome to enhance it and allowed to fork it, as long as you
respect the license conditions.
If you're not the only one with this requirement, your
enhancement can be accepted for the main fossil trunk, as
long as that behaviour is optional.

> I seem to remember a recent discussion about
> this issue, but I am having difficulty locating it.
> 
> Thanks!
> 
> -Clark

HTH
-- 
  (  Kees Nuyt
  )
c[_]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[prev in list] [next in list] [prev in thread] [next in thread]