We are looking at adopting bootstrap for all internal applications. We want to create a bootstrap theme for url_shortener.

Rick wants to add this feature to BTON and make it a standard element in our UI kit.

I am not sure what he's exactly wanting, a button that links straight to a Helpdesk ticket? More discussions should be had with Rick and the apps team.

We are moving away from CAS authentication and will be using ADFS authentication in the future. Additionally, we plan to provide the role membership by using AD groups. This means there is no longer a need for a people table at all, since all user information will be coming from ActiveDirectory.

Folks are checking the Destination Preview box when creating short urls without realizing what this does or how to change this after the url is created.

Possible tasks to address this:

• Text or image next to the checkbox that expresses a Preview's intention
• Text near the checkbox stating this option can be changed after creation

Old BTon would warn a user in the Add URL screen if they were adding a preexisting short URL.

Regular staff should only edit URLs that they created. Administrators should be able to edit any url.

Based off staff feedback, we found it's important for folks when they scroll through All Urls to see the original url to quickly know its content.

Notes

• Showing the full destination url is ideal but many of the Urls in Bton are very long.
• Wrapping is not perfect and browsers choose to wrap at different points.
• Add description or title field instead and require it when adding a new url?

The old Bton had a description field and staff sometimes used the description field to help remember what the destination url was. After all, really long urls are hard to identify what they're actually for.

The description field needs to be added back to the application, and import legacy data from the old system.

With EPL, we have a desire to provide short URLs to any permit, plan, code case, or invoice. All these records in EPL use 36 character UUIDs as the URL parameter. However, citizens will only know the permit number, invoice number, etc.

To provide a short url to these things, this application will need to be able to query EPL to look up the UUID primary key for a given permit number, invoice number, code case number, etc. These numbers all have standard patterns that we could regex for.

A temporary fix was made to the url's Code Pattern to accept all characters (.*). We should explore why the Code Pattern's original Regex stopped accepting code entries even if the entry was valid.

If you attempt to visit bton at a particular sub-url, rather than the root, the application does not remember what url you were trying to access. Instead, after login, it redirects you back to the homepage.

The application should remember where in the site you were attempting to visit and send you there after successful login.

Adminsitrators should be able to edit anything in the system, but cannot.

People in the AD admin group are expected to be assigned the Admin role in the application. The Admin role should be able to edit anything. I am unsure whether it's a failure of role assignment during login or role permissions.

AuraPHP has a new version of the sqlquery library

Often, we want to assure citizens who follow our tiny links that we're not trying to trick them into going to nefarious websites. Because the tinyurls and the QRCodes are opaque, we can try to set them at ease by rendering a webpage at the ShortURL location, instead of just doing an immeditate 302 redirect.

The page rendered at the Short URL location should show the Short URL as well as the Original URL they're going to. We could probably even show the QRCode...people could be arriving having used the QRCode on their phones.

The application currently autogenerates a random five character code using a pool of defined characters. However, a user can type whatever they feel like as a code when adding and editing.

The resulting short Url will be correctly url_encoded and the encoded version will work. Even so, it might be surprising for users to not get the verbatim characters they typed as part of the Url.

To avoid this, we could have the application restrict users to the same pool of characters that are used in the random gerenation of codes.

A qrcode is just a fancy way to encode any URL. It doesn't have to be the short one. It could be desirable to have a qrcode that represents the destination url. This has two benefits:

• it saves a redirect
• it allows preview of the real Url when using the qrcode

These days, qrcodes can be created using built-in features of the browsers. Chrome and Edge both have native qrcode generation for any url. Still, it could be useful to have qrcodes that all look like the rest of our city-generated qrcodes.

Each browser that generates qrcodes creates them with a distint look.

The five character limit makes sense for auto-generated codes. However, staff often want a nice, readable code for publishing. Often the readable code is larger than five characters.

We should keep the auto-generated code length to 5, but allow staff to enter longer codes, if they want.

Rick wants folks to see the entire URL before submitting it for shortening.

We want to have additional colors available for the qrcodes. In addition to black-on-white, we want white-on-blue and blue-on-white.

The color values should come from the theme's color pallete

The path for the image is not valid in production, where we host the application at the root of the webserver.