shevett / congo Goto Github PK

Need an interceptor in the public pages that checks for an active registratnt session when rendering a page so that it redirects to Welcome if one is not there - similar to how Coconut works.

Responsiveness from trac ranges from acceptable to horrible, semi-randomly.

See jsp/public/NotConfigured.jsp.

As more and more options are added to the congoproperties page via the schema, the number that require a session expire drops. For instance, changing the server port for SMTP connections should not force a logout / login.

The handler for property changes should be smart enough to know whether a change will require a login.

If no registration types are available (either due to many disabled or whatever), the registration page should state as much. Right now it just says Select ar egsitration type and shows nothing.

The green bar header on the my home / regstration / whatever pages in the public interface have no dates. What's up with that?

When using 'Void' on an active invoice, it should remove it from the active queue (doesn't show up in the upper right part of hte screen)

A set of utility classes was written into v1 to 'merge' duplicant registrant ID's into a single ID, and getting rid of the old ID. This functioanlity needs to be implemented in v2. It will be required before deploying to Arisia.

When registering, when you check options they do not get added to the purchase price. Note that this may be negated by making Add-Ons work, but for now, pay-for properties need to be put into the registration screen.

A link to the email contact for the convention is needed in the footer of the page.

Need to be able to transfer a membership from one person to another

The browse screen in coconut is display only, the various filters do not work.

When liquibase creates a new data structure from scratch, much of the default data for the convention 1000 is wrong - dates are in the wrong format, and the default stylesheet is unnecessary.

The properties mechanism in congov2 needs to be overhauled, re-schemaed, and documented. It needs to allow:

• Arbitrary properties to be set on attendees
• Defaults for this con, all cons, all registrants
• Local values override system defaults

Existing schema is very difficult to work with.

A mechanism that allows intelligent querying of the print system is needed to identify potential logjams in the print routines. Either within Coconut or externally, a live display showing what printers are online, what their status is, what load they're taking, and a total badge count is needed.

We have had problems where printers shut down in mid-run, and there's no way to tell why there are no cards coming out of a printer, nor is there a simple way to restart the queues to enable pooling.

This is primarily a CUPS issue, so will likely require making calls to CUPS to find out status.

Steps to reproduce:

1. Go to the phone number edit page for a user.
2. Change an existing phone number's location.
3. Attempt to save.

Expected:

• Phone number is retained under a new location.

Actual:

• Changes not saved.

It should be showing a landing page indicating that CONGO is not yet set up, and instructing the user on how to set it up.

After creating a new registrant in the public interface, it jumps directly to 'register...' but the registration page has no information available - no reg types or properties or the like.

Coconut needs a payment gateway configuration section that allows an administrator to set up Paypal and Authorize.net payment methods. It should allow for target urls, parameters, a simple 'test mode on/off', and a way of displaying transaction history / status of previous attempts to allow debugging without needing to log into the server.

Question - where is payment gateway configuration data -stored-? Iniital thoughs are putting it in the congo properties configuration file. It is 'single row' data, and more appropriate for properties than for storing in a configuration table.

If you go into edit event details and change the dates, they don't save.

Correction - it tries to save, throws an error. Big problem is the error is not being shown to the client :

Caused by: java.text.ParseException: Unparseable date: 2009-07-15
at java.text.DateFormat.parse(DateFormat.java:337)

If I let Eclipse auto-restart CONGO after a change, the next hit generates the attached error. If i manually shut it down and restart it, it works fine.

This is a fairly recent development - perhaps in the last 2 months.

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
org.apache.log4j.Category.isEnabledFor(Category.java:746)
org.apache.commons.logging.impl.Log4JLogger.isTraceEnabled(Log4JLogger.java:333)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
java.lang.Thread.run(Thread.java:619)

The recover password function is not complete in the public interface. Finish the pages and implementation.

A way of deleting a registrant from the database (completely) is needed.

The 'rounded box' on the right side of hte public interface is pink - it's incidental / adde dinformatioin for the user, not a warning. Should be a little more subtle.

Hookay, this one's a technical oddity. Bear with me.

Certain actions' bean definitions include property references, usually to ${preferredcid}, that may not exist yet. Struts attempts to create these actions well before checking the interceptor stack to see whether it will ever call any code on the action. When the configuration parameter is not set, Struts sees Spring's bean creation failure exception and fails the request, even if subsequent filtering would've gone to a normal result.

The easy solution is to tag the affected actions' beans with <aop:scoped-proxy />, which will give Struts a proxy object to play with without necessarily creating the target object. However, because many of the actions in Congo expose public members (someAction.foo) instead of getters (someAction.getFoo ()), Spring's AOP support hides these properties, breaking downstream JSPs.

The fix is a two-parter:

1. Replace public members with the necessary get, set, or get/set pairs.
2. Add <aop:scoped-proxy /> to bean definitions for actions that directly depend on configuration properties.

This does not affect requests for congo/, congo/coconut/, or congo/public, which have been adjusted not to tickle the bug. However, requests for (eg.) congo/public/Welcome or congo/coconut/showloginpage will hit the bug if Congo is not configured. These pages should be redirecting to the config page, not showing an error to the user.

When creating a new registrant in the public interface, all teh contact information (address / city / state / email) is not being saved at all. Oops.

Clicking edit or add on an existing or newly created registrants fails with this error (and why is 'instantiate' spelled wrong? :)

Unable to intantiate Action!
com.opensymphony.xwork2.DefaultActionInvocation.createAction(DefaultActionInvocation.java:283)
com.opensymphony.xwork2.DefaultActionInvocation.init(DefaultActionInvocation.java:381)
com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:187)
org.apache.struts2.impl.StrutsActionProxy.prepare(StrutsActionProxy.java:61)
org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:39)
com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:47)
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:467)
org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:467)

Once the new properties schema is in and documented, the properites editors in Coconut needs to be written to allow creation and maintenance of properties as well as editing on a per registrant / per event level.

Whenever a change is made in the location or contact information, a history record should be added recording who made the update.

The text and prompts in forgot password are inconsistent with the rest of the site (uses proper nouns, etc). Needs cleanup.

When creating a new registration type or a new property configuration, the required fields should be indicated so there aren't NPE errors.

The code should make sure the required fields have data. Non-required fields should default to something reasonable.

When an invoice is processed, use the current active gateway to process the transaction. Cash naturally does not use a gateway.

The create registrant page on the public interface does not have the rounded boxes / layout we're using now.

A method to grant a license to an CONGO installation needs to be designed and implemented. Likely a key generation that happens at Stonekeep and is issued to an installer.

The license should be easy to read and generate, and have a defined structure of limitations (number of users, number of events, etc)

After [ticket:16 the previous issue] on startup, i was able to work in coconut for a while. Made a change, saved, restarted tomcat, noted errors and a failed deploy.

Full trace of startup with tracebacks is here:
http://pastebin.stonekeep.com/5559

The buttons in the lower right of the tool bar across the public interface have inconsistent layouts. Cancel should always be on the right, etc etc.

On the registrant screen, there are many options enabled that should be disabled given circumstances.

For instance, you should not be able to unsubscribe a registrant if they are registered. You should not be able to check in someone if they haven't been badged, etc etc.

The public pages use a CSSFetcher class to feed in the stylesheet from the con_details table. They also use a 'starter' web.css file before loading via the fetcher.

The fetcher should load the default web.css file, then feed the local customzations out to the JSP engine, rather than use 2 lines in the JSP. That way we can alter themes within Coconut by changing which css files are fed out to the pages without having to alter the local files.

Creating a new registrant in the public interface with the same firstname, lastname, and badgename allows duplication of records. Need some checking here.

I created a new user in the admin interface (admin > create new user) and most of the data populated except for the phone number. The system recognized that I had entered one but didn't save the data.

The 'editphone' methods in EditRegistrantLocations are using session variables to store state between initial setup, form display, and update database. This is because I couldn't figure out how to get Struts2 to keep state on a complex object through Prepare->Render->Update.

Rework this so it's done 'right'

A script or tool needs to be written that will import / migrate an existing Congo v1 database into a v2 structure. This could be a built in class in congo, or an external script (Jython?)

Remote users need to be able to complete and pay invoices generated via the public interface.

When a form validation error happens (return 'input'), the ${message} parameter is in the same font / style as the rest of the page, and is easy to miss. Get it it's own style and change pages accordingly.

'currentevent' is stored in the session var. When clicking 'logout', it's not destroying the session properly.

After creating a login, the registration page says No registration options available, but if yo hit cancel, go back home, and click 'register', options appear.

I got the 'you have successfully installed congo' dialog. All defaults were correct for my install, I clicked OK. Got a liquibase 'table exists' error:

http://pastebin.stonekeep.com/5558

When mousing around in coconut, you can mouse over the long bar at the top, which is a link to home. It also shows a green background on the 'hover', which looks awful. Remove the hover color just for that bar.

A registrant needs to be able to change their own personal information. (badge name, full name, phon enumber, email address, etc)

When a public user creates an account, ther'es no way to specify a password.