{5} Assigned, Active Tickets by Owner (Full Description) (5 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

benoitg

Ticket Summary Component Milestone Type Created
Description
#92 Opening the firewall if the auth servers are all unreachable Gateway and Auth server Gateway 1.1.5 Feature Request 03/02/06

The goal is to have an option to open the firewall if the auth servers are all unreachable ...

Here is the current suggestion from Rob Janes:

Add a new chain, TABLE_WIFIDOG_AUTH_IS_DOWN, on the mangle, nat and filter.

On the PREROUTING mangle, the chain is there, at the very end, but normally empty. When the heartbeat monitor thread finds the auth servers are unreachable it adds a line to mark unmarked packets with a new mark, FW_MARK_AUTHISDOWN (253).

When the heartbeat monitor thread finds the auth servers are responding again it clears the above mangle chain.

Similarily, in the nat PREROUTING chains, add a check for mark FW_MARK_AUTHISDOWN just before the redirect of port 80. If that mark is set, accept the packet. This bypasses the redirect.

In the filter FORWARD chain, add a check for the FW_MARK_AUTHISDOWN just before the jump to the TABLE_WIFIDOG_UNKNOWN chain. If the mark is set, jump to the filter chain TABLE_WIFIDOG_AUTH_IS_DOWN. This chain is loaded at firewall init time from a ruleset, 'auth-is-down'.

If you leave the 'auth-is-down' ruleset empty, everything stays the way it is now.

But, if you do 

FirewallRuleSet auth-is-down {
  FirewallRule allow to 0/0
}

all customers will be allowed to surf while the auth server is down. As soon as the authserver comes back up, they will be redirected to the login splash since the heartbeat monitor will clear the chain that marks their packets as FW_MARK_AUTHISDOWN, and then their packets will no longer be specially marked.

That's it''

max-horvath

Ticket Summary Component Milestone Type Created
Description
#243 Display meaningfull names for content types Auth server, Usability, Interface and translations WifiDog Auth Server 1.0 Bug report 09/03/06

Content types should be displayed with meaningful names instead of their class names.

#114 Don't show edit link to content a user is not owner of Auth server, Content Management WifiDog Auth Server 1.0 Bug report 03/22/06

On the node administration site you can add content as an administrator.

But if another user who is owner of this node wants to edit this content, he's unable to save his changes (the old content will be shown, as he is not an owner of this content).

So we should only show the edit link for content which a user wouldn't be able to edit. Otherwise it's quite confusing.

#115 Don't automatically show additional empty language variant of a content Auth server, Content Management WifiDog Auth Server 1.0 Bug report 03/22/06

For a lot of users the principle of languagehandling is quite confusing.

Most of the time users wonder, why the second string of i.e. a langstring won't be displayed.

So everytime I (or others) have to explain, that they must create a second langstring object, because the second string of the first langstring object is just for providing another language version of the first string.

I think this can be solved very easily ...

Instead of showing the second string automaticaly we should just have a button "add another language" which would display the second string. This way it would be much more clear, why and whatfor we have multiple strings/versions for one object.

#17 Disclaimer (terms of service) support. Auth server, Feature request WifiDog Auth Server 1.0 Feature Request 06/28/05

Explicit disclaimer (terms of service) support. This is essential for ISF, and is the ONLY thing many groups want. When logging in for the first time (or everytime for splash-only hotspot), the user has to agree to the terms of service (which will be a content type).

Note: See TracReports for help on using and creating reports.