an approval process automation tool
Home Page: https://cap.18f.gov
License: Other
C2 is part of GSA's suite of Common Acquisition Platform (CAP) tools.
C2's code is open source, which means you can clone the code in this repository, adapt it for your needs, and deploy it yourself.
If you would prefer to use C2 as as hosted software solution for your organization, we would be happy to give you a demo.
Please submit a support ticket to learn more.
To qualify for an ATO we need to add extra logging around many actions.
TOLOG:
The good news is: this app has a lot of great tests!
The bad news is: it is hard to figure out if there is test coverage for a feature or not.
Part of the reason for this is that we are using various spec types in unusual ways.
Examples:
Controller specs
What they should check for: rendered templates
redirects
database changes
instance variables assigned in the controller to be shared with the view
What we are using them to check for: flash messages
database changes
emails sent
redirects
Request specs:
What they should check for: everything controller specs check for + response body
What we are using them to check for: same stuff we are using controller specs for
Feature specs:
What they should check for: Feature specs are high-level tests meant to exercise slices of functionality
through an application. They should drive the application only via its external
interface, usually web pages.
What we use them to check for: database changes
emails sent
redirects
content on page
As might be obvious, now that you read the above lists, we are using controller, request, and feature specs in almost the same way.
I vote for the following refactor:
Update feature specs from the perspective of a user clicking around the application and filling in forms. This means the spec expectations would also be for items on the page rather than looking at the database in an expectation (eg: "Proposal.find(1)`)
Consolidate controller and request specs. I would vote to move controller specs to be request specs because they test at the same level but have the added benefit of allowing to check for the response body.
This is just a suggestion and I am definitely open to others' ideas. I do think this refactor is warranted in some form, though, because right now it is very difficult to determine whether a feature is covered by specs due to all of the overlap.
just wanted to capture this comment in a more visible place than my inbox.
Because YouTube's automatic captioning...le sigh.
The web experience for Communicart is a place where users can see all of their pending purchase requests, and all past purchase requests. There are two main user groups: Requesters and Approvers.
For the approver:
For the requester:
For the approver:
For the requester:
So far this page is the same for Approvers and Requesters except for the header on the page.
The only thing I haven't designed yet, is the ability to upload receipts and other documents that can help confirm that the purchase has been made.
The main thing that isn't working right now, is the pending and approved status bugs. I need to keep playing with the styling of those.
Just submitted an order for business cards (Request #6474), and after submitting noticed that the purchase type displayed is not correct.
When I edit the order, it appears that the correct purchase type is displayed.
However, when I close out of editing, the incorrect type shows again.
The GSA IT team found this via WebInspect, and should confirm that it's resolved once the issue is closed. This would potentially allow tampering with the cookies, even if the rest of the site is served properly over HTTPS.
If we're lucky, this is just a matter of changing https://github.com/18F/C2/blob/master/config/initializers/session_store.rb.
Hi. I just cloned this repo and it ended up being 83MB. The biggest file is a 77MB pack in .git/objects/pack.
To see the 10 biggest files, run this from the root directory:
git verify-pack -v .git/objects/pack/pack-7b03cc896f31b2441f3a791ef760bd28495697e6.idx \
| sort -k 3 -n \
| tail -10
To see what each file is, run this:
git rev-list --objects --all | grep [first few chars of the sha1 from previous output]
Most of the files are .png, and the last one in the list is a .mov, which I would guess takes up most of the space. There are also .csv and .pdf files. The next step would be to clean up your git by removing all of those unnecessary files.
One option is to use the bfg-repo-cleaner tool, which worked great for me on other repos I've tried it on.
Alternatively, you could do it manually following this git article, as outlined below:
git filter-branch --index-filter 'git rm --cached --ignore-unmatch *.mov' -- --all
rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc --aggressive --prune=now
Then repeat with other types of files.
Then verify:
git count-objects -v
Your size-pack should be a lot smaller now.
Validations from forms show up on the main page (and possibly other pages).
Steps to reproduce:
Bring visibility to the following:
For those not familiar with the CAP project, we are managing approval workflows for different groups in the executive branch, at the moment focusing on purchase card holders getting approvals from supervisors.
We have multiple clients needing approval workflows, but all are sending different information through different templates. One group, for example, is "forwarding" GSA Advantage carts (which copies the order information into the email), whereas another is (in the near term) going to be sending a work order as a spreadsheet. With the current architecture, the size of this codebase will grow linearly with the number of different groups (specifically, the number of types of workflows) we need to support, in terms of parsers, templates, etc.
We need to start splitting the generalized approval functionality from the client-specific functionality. More specifically, let's separate the email templates from the approval logic, so that C2 (or whatever we rename this central piece to) knows nothing about Navigator, carts, etc). The central piece would essentially be a state machine that
Options:
Many of 18F's other projects are service/API-oriented, having a central server which our clients can communicate with through REST.
In this setup, each client would create a new Rails/Rack app that includes the common functionality as a gem.
Questions? Thoughts? Alternative ideas?
When creating a new event, a Supervisor must be selected from a select box. The options are not sorted and are formatted in various ways. There are also people on there who are not still employees in TTS. It is extremely difficult to find and select the correct person from this box.
My workaround was to inspect the page's HTML with DevTools, where I could search for the option corresponding to my supervisor and then manually add the selected attribute.
I selected "monthly" but it shows up as "daily." when I try to modify it it's still on "monthly" but when I cancel it shows "daily."
If there is a form that is processing the submit, then make remote: true
Then set up a js response on the controller and create a .js.erb that responds according to the form_for endpoint
ie. js response: https://github.com/18F/C2/blob/design/new-details/app/controllers/observations_controller.rb#L11-L18
ie. .js.erb file: https://github.com/18F/C2/blob/design/new-details/app/views/proposals/js/observations.js.erb
Use the .js.erb file to render the content/template that needs to be rendered in the page. Try to use as much of the existing JS files functions. Keep as much logic out of these .js.erb files and try not to pollute the global namespace with variables.
ie. https://github.com/18F/C2/blob/design/new-details/app/views/proposals/js/observations.js.erb#L9
According to Ric, these are two separate steps that would make more sense as one-- maybe allow the message/comment to be sent when "Approve" or "Deny" is hit?
c2-dev (or c2-staging)cap organization on Cloud Foundry (cf set-org-role USERNAME cap OrgManager)ADMIN_EMAILS)c2-dev (or c2-staging)[email protected], [email protected], and gatewaycommunicator
capdevs, communicart.sender, and gatewaycommunicator through IT Service Deskcap organization on Cloud Foundry (cf set-org-role USERNAME cap OrgManager)admin to User record)c2-dev (or c2-staging)[email protected], [email protected], and gatewaycommunicator
capdevs, communicart.sender, and gatewaycommunicator through IT Service Desk[email protected]cap organization on Cloud Foundry (cf set-org-role USERNAME cap OrgManager)admin to User record)We currently have documentation about the project scattered around:
which seems like too many. At the very least, I think we can make the messaging more consistent. There are a handful of audiences that we want to speak to:
Questions:
Would love some content (and content design) help!
c2-dev (or c2-staging)[email protected], [email protected], and gatewaycommunicator
capdevs, communicart.sender, and gatewaycommunicator through IT Service Deskcap organization on Cloud Foundry (cf set-org-role USERNAME cap OrgManager)admin to User record)All attachments that users upload are public, at least in the public facing version of the app.
Steps to reproduce:
We have several stories open related to improving the experience of proposals search:
These stories boil down to: make search faster, give users more fields to search within and advanced options, support pagination (and presumably, though not yet mentioned, sorting by any field).
There are a few aspects of our data model and code architecture that make improving search a non-trivial problem:
proposals, client_data, comments, versions, and attachments.users and roles.The current implementation uses a big block of hard-coded SQL plus some ActiveRecord associations in order to create a very large, multiple-JOIN query, which includes manual calls to Postgres full-text search functions for every column against which the user wants to search. The current implementation does zero pagination or user-controlled sorting, and does not distinguish between client slugs (all proposals are searched, regardless of the user's client_slug value).
Current search usage indicates that 80-90% of searches are simply for the public_id of a known proposal. That use case could be solved far more simply and with better performance than the current implementation supports. However, it may be that the high percentage of public_id searches is because the existing user base has figured out that the current search feature doesn't really support much more than that. Only a small minority of client_data fields are searched, comments are ignored, multiple search query terms do not behave as expected, and performance is slow. I.e., our data might indicate a narrow need because users have self-selected a cow path that fits the existing feature constraints, not their actual business needs.
I see three distinct ways forward.
client_slug and interrogating the relevant client_data model class to autogenerate the Postgres full-text search syntax. This allows us to add new client models and write very little custom search SQL.Rewrite the search features to use the industry standard pg_search gem. The multisearch feature should support our normalized data.
NOTE I looked at textacular as an alternative gem but it does not have a multisearch-like feature and so our normalized data structure would prove a challenge to its simpler feature set.
Offload search entirely to an external service. Query parsing, ranking, sorting, pagination, highlighting, would all be performed by ES.
Elasticsearch. Best performance, least amount of code.
The request submission page has way too many page refreshes. Validations should be done on the client side (I see you already have a case for that - 98157690). Comments and attachments should be done through AJAX.
We've been getting some C2 API-related errors on Micro-purchase and some digging has revealed that the first step of the OAuth handshake fails:
Request:
MY_OAUTH_KEY=[redacted]
MY_OAUTH_SECRET=[redacted]
MY_CREDS=`echo "$MY_OAUTH_KEY:$MY_OAUTH_SECRET" | base64`
curl -i -X POST -H "Authorization: Basic $MY_CREDS" \
-d 'grant_type=client_credentials' \
https://c2-staging.18f.gov/oauth/token
Response:
HTTP/1.1 401 Unauthorized
Cache-Control: no-store
Content-Type: application/json; charset=utf-8
Date: Mon, 17 Oct 2016 15:16:21 GMT
Pragma: no-cache
Server: nginx
Vary: Origin
Www-Authenticate: Bearer realm="Doorkeeper", error="invalid_client", error_description="Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method."
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: a8d01689-5020-4840-beba-b4b51261d56d
X-Runtime: 0.012835
X-Vcap-Request-Id: cad626f8-f8eb-4bd7-5965-aee2d898abc7
X-Xss-Protection: 1; mode=block
Content-Length: 173
Connection: keep-alive
{"error":"invalid_client","error_description":"Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method."}%
We had this same error inside the Micro-purchase app (using the C2::Client class--from https://github.com/18F/c2-api-client-ruby).
As we start to dogfood this more inside 18F, it would be good to settle on a single name -- cap.18f.gov (CAP), CommuniCart, C2... C2 is of course easy internally, but will probably lead to confusion as we onboard more people.
$0.02
Date being rendered is not accurate. Example:
The date at the top, 10/24, is accurate. The one in-line from April is not.
Continuing this conversation via #1011 @jessieay
So this is the part that makes emails complicated.
Most web pages are written with the assumption that all the content is loaded, then the CSS determines the priority for styling. In emails, you have to design your CSS/class/markup base on the assumption that you can have some parts of your code NOT run.
When it comes to responsive layouts, you have to design for the care where desktop is default (without the media queries) and any media queries are added, only if its possible to run inline styles. In the case where you have things like Gmail, where the style tags are stripped out, you need to account for this.
The problem with Roadie was that it was inlining the media query styles that would run on mobile, which broke the default desktop layout. By having roadie ignore certain styles, we control the designed layout to render the desktop mode in all cases, and then serve the inline style tag with media queries to be run where possible.
To make things more complicated, Outlook is very outdated. Specifically, there are a lot of CSS3 properties and even CSS2 properties it doesnt render. As a result, outlook has some legacy hacks where you can use comment flags to tell Outlook NOT to render certain content.
For what its worth, we are putting these things into consideration in our templates : )
This would be really helpful for avoiding duplicates where there are multiple requestors in the same office.
c2-dev (or c2-staging)[email protected], [email protected], and gatewaycommunicator
capdevs, communicart.sender, and gatewaycommunicator through IT Service Deskgsa.approver, communicart.budget.approver, and communicart.ofm.approver)cap organization on Cloud Foundry (cf set-org-role USERNAME cap OrgManager)admin to User record)Looking over the API documentation, I noticed that the documentation has outdated URLs and does not describe the authentication/authorization flow. Thanks!
Biggest updates:
Biggest updates:
Minor issue, but the "purchase type" pulldown selector on the new purchase request form is missing the chevron icon.
I'd fix myself, but it would take me a while to find the file :/
This is the fix, i believe …
It will help those who visit our github organization.
Proposals require a way to depict having multiple line-items and multiple vendors.
Reference doc: https://docs.google.com/document/d/1_gjq_3m16Ug7_JcfsV28Lt4dCQTDnEhvWVFofbNaw4g/edit
Reference issue: 18F/C2: Issue #1151
This is a potentially huge help topic, but I think it's both easier to describe/write and easier for the user if it exists within the submission form. Instructions provided with the form itself are more likely to be noticed and followed.
As an example, the current dollar amount (actual or estimated) requires submissions to be formatted without commas, as in 9999.99 or 9999 rather than 9,999.99 or 9,999. Under "Amount" but above the actual form, a micro-instruction like Do not use commas. (Example: 1050.25).
If there are other submission fields that might have similar points of confusion, put the instruction briefly with that field. If the instruction is too long (more than, say 50 characters) insert a link to a help topic elsewhere.
There does not seem to be limits on the attachment data volume. I uploaded >50 MB worth of attachments and could submit the request just fine. There should also be a validation around the data size per attachment - a 10MB attachment went through fine, but 30 MB came back with a 502.
There should be limits on the size of the attachment and the total number of attachments per request.
Coordinate with @24thcentury
If Zonebie chooses Auckland as its random timezone, two tests will fail. Any other time zone will not (to my knowledge) cause these tests to fail.
In particular:
rspec ./spec/mailers/communicart_mailer_spec.rb:78 # CommunicartMailer actions_for_approver creates a new token
rspec ./spec/models/api_token_spec.rb:16 # ApiToken.create sets the expiry
This bug can be reproduced by running the tests in the Auckland timezone manually:
ZONEBIE_TZ="Auckland" rspec
The story behind this one: our only 18F P-Card holder has been on leave and people have been wondering about the status of their already approved Communicart requests. Is there a way to easily integrate an order status tracker so we can see if approved purchases have been ordered? Maybe it would include a link to a shipping number that users can verify?
If you enter in a long title, the server comes back with a 500. There does not seem to be a limit in the description field. For the title, a limit should be set so that it display properly on the UI. For the description, some large but reasonable limit should be set to guarantee limits on the data storage in the DB. When submitting a large (eg., 10 MB) description, the server comes back with 502: bad gateway. 1 MB descriptions go through just fine.
I realize this is mostly an internal tool and ideally you should not have malicious users, but it is good practice to always put limits on fields that the user provides.
C2 currently uses Mandrill for email delivery. We need to move off before the end of March. For more details: https://github.com/18F/Infrastructure/issues/880
As well as provisioning an account on a new email service, this will require a minor code change in https://github.com/18F/C2/blob/master/config/environments/production.rb#L6 . It's probably best to move this config out to the c2-prod-ups-email CF service, in which case it should go in https://github.com/18F/C2/blob/master/app/credentials/email_credentials.rb .
In the new interface, requests don't seem to be canceled by clicking the cancel button, entering a reason, and confirming. This behavior still works properly in the old interface.
Biggest updates:
Things I still need to work on:
Larger questions:
Hello again C2 team!
18F TeamOps has found Communicart really helpful and is thinking a little more about "what's next". We are thinking of ways to easily explore the data generated by the many requests made by an organization. Here are a few of our needs:
A few of these ideas have been mentioned in other issues, but consider this as a more "global" issue of considering how to assess what data an organization will need to pull from Communicart. Here is my idea:
For all 18F requests from the general staff, we can use this Google form which will populate this sheet.
TeamOps staff can then use Communicart to get Ric's approval, and we use the additional fields provided in the sheet to track order status, approvals, and arrival confirmation in inventory. Would it be helpful for you all if we switched to this system so that you could easily observe how we interact with the data that we need?
Should read, "Here are details"
Highlighted in screenshot below:
c2-dev (or c2-staging)[email protected], [email protected], and gatewaycommunicator
capdevs, communicart.sender, and gatewaycommunicator through IT Service Desk[email protected]cap organization on Cloud Foundry (cf set-org-role USERNAME cap OrgManager)admin to User record)
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.