profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/cgunther/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Chris Gunther cgunther Room 118 Solutions New York, USA http://room118solutions.com

cgunther/bootstrap 3

HTML, CSS, and JS toolkit from Twitter

cgunther/event_calendar 2

Show multiple, overlapping events across calendar days and rows. Rails plugin.

cgunther/cancan 1

Authorization Gem for Ruby on Rails.

cgunther/CodeIgniter 1

EllisLab's Open Source PHP Framework

cgunther/enumerize 1

Enumerated attributes with I18n and ActiveRecord/Mongoid support

cgunther/actv 0

Library for Using Active.com's v2 search API

cgunther/airbrake 0

The official Airbrake library for Ruby on Rails. Links to other Airbrake libraries are in the ReadMe.

cgunther/also_migrate 0

Migrate multiple tables with similar schema at once

cgunther/apt 0

Development repository for Opscode Cookbook apt

issue commentmattheworiordan/capybara-screenshot

Screenshots are not taken when using multiple windows

@Intrepidd @wallyaltman check out #287 for a fix

Intrepidd

comment created time in 2 days

pull request commentmattheworiordan/capybara-screenshot

take screenshots of correct window

@trcarden check out #287

dreyks

comment created time in 2 days

PR opened mattheworiordan/capybara-screenshot

take screenshots of correct window (Updated)

This is a continuation of #245, starting with @dreyks's work and trying to address @mattheworiordan's feedback

+37 -13

0 comment

2 changed files

pr created time in 2 days

PR opened roo-rb/roo

Fix internal use of deprecated `Excelx::Cell.new`

Calling Excelx#set internally called Excelx::Cell.new, which is deprecated in favor of Excelx::Cell.create_cell.

I tried using the recommended Excelx::Cell.create_cell, however it expects a type as the first argument. #set tries to infer the type via cell_type_by_value, however it only returns :float or :string, but Excelx::Cell.cell_class doesn't support :float.

Even if I add :float to map to Cell::Number, then there's a dilemma because Excelx::Cell.create_cell passes all the arguments except the first onto the specific cell class, but the arity of Cell::String is 5 whereas the arity of Cell::Number is 6, meaning Excelx#set would need to initialize each cell class individually to pass the appropriate arguments.

Therefore I landed on simply using Cell::Base. It's probably not the most accurate, but given persisting the spreadsheet isn't an option, the uses for Excelx#set should be minimal. In my case, I simply use it in testing to avoid creating new files for every possible scenario, opting to manually set various cells to triggered assorted scenarios.

Fixes #529.

+1 -1

0 comment

1 changed file

pr created time in 3 days

create barnchcgunther/roo

branch : fix-cell-new-deprecation

created branch time in 3 days

fork cgunther/roo

Roo provides an interface to spreadsheets of several sorts.

fork in 3 days

push eventcgunther/rspec-pdf_diff

Chris Gunther

commit sha 2922690590db0d802e41c9ab79257ec45145c5f4

Stop depending on bundler for development Not sure that's a common practice? It was way outdated anyway.

view details

Chris Gunther

commit sha 8a28445974f0f1c184a567ffbae777451622fc2e

Cocaine was renamed terrapin

view details

push time in 3 days

push eventcgunther/rspec-pdf_diff

Chris Gunther

commit sha 67f6ecab80bed8eb34a60d9dbd380b9a3b9d19bb

Force intermediary PNGs to be 24 bit If the source PDF is black and white, ImageMagick will try to convert to grayscale, but then it seems to complain that the RGB color space (I guess from the source) is not permitted on grayscale PNG. Forcing PNG24 avoids the grayscale conversion, and thus the warning.

view details

push time in 3 days

delete branch cgunther/netsuite

delete branch : avoid-repeating-field-in-read-or-search-only

delete time in 18 days

issue commentroom118solutions/branchbot

git checkout without arguments from branch saves branch dump as master

Ah, right, it's post-checkout, so I guess that means by the time this runs, the current branch is the target, not the source. Mentally, since branchbot hasn't returned my terminal yet, I assume the branch hasn't actually changed, but that's likely wrong.

This was a once-in-seven-years issue, so certainly no urgency, just wanted to document it while it was fresh.

cgunther

comment created time in a month

issue commentroom118solutions/branchbot

git checkout without arguments from branch saves branch dump as master

Yup, check out a new branch foo, mess with the DB without committing anything, then do something to trigger branchbot.

If you don't mind depending on git output, git branch shows an asterisk next to the current branch:

$ git branch
  foo
* bar
  master

On old capistrano deploys, we used to grab the branch name for staging like:

`git branch` =~ /\* (\S+)\s/m
puts $1
=> "bar"

We conditionally set it as the deploy branch as I'd guess it may not mark a branch if you're in detached head mode, where you have an individual commit checked out (or maybe a tag too, or maybe even in the midst of an interactive rebase).

cgunther

comment created time in a month

issue commentroom118solutions/branchbot

git checkout without arguments from branch saves branch dump as master

In both of your examples, I agree because you're not actually changing branches, however I don't think that's the extent of possibilities for both heads matching. Imagine this scenario, starting on master:

$ git checkout -b foo
# Dumps master

# Do something manipulating data without committing code changes

$ git checkout master

The heads match, so we can assert no code changed, however we can't guarantee no data changed. In a perfect world, we'd almost need a "head" reference from the database. Certainly an obscure case, but theoretically possible.

Maybe this is a scenario we prompt for what to do, assuming prompting is possible within a hook?

cgunther

comment created time in a month

issue openedroom118solutions/branchbot

git checkout without arguments from branch saves branch dump as master

I just hit this, didn't get a chance to dig in, but documenting it a bit for future self.

If you're on branch foo and run git checkout (no arguments, meant to run git checkout . to discard changes in my working directory), git leaves you on branch foo, but the hooks seem to cause branchbot to dump the state of the current database (branch) as master, which effectively just blew away your master dump, replacing it with your feature dump.

I'll have to come back and test this a bit more to confirm, but assuming that's reproducible, I'd be curious if we can catch this and do something better, either not dumping at all (you're not really changing branches), or at least not dumping to master.

created time in a month

PR opened NetSweet/netsuite

Avoid repeating field definitions

In adding the start of search_only_fields, a couple standard fields were mistakenly re-defined as search_only_fields, which ended up excluding. them when pushing data to NetSuite, under the guise they were search-only.

Now it's impossible to define the same field twice.

As a result, had to fix a number of occurrences of fields repeated between fields and another definition (ie record_refs, read_only_fields, field).

The only notable fix is on Invoice, where bill_address and ship_address were previously defined as fields, then got repeated as search_only_fields. In old APIs (<= 2014.1), these seemed to actually be fields, however in newer APIs (>= 2014.2), they no longer are. I'm erring on the side of newer APIs here, removing them as fields and leaving them as search_only_fields.

Fixed #486

+66 -35

0 comment

20 changed files

pr created time in a month

create barnchcgunther/netsuite

branch : avoid-repeating-field-in-read-or-search-only

created branch time in a month

issue commentNetSweet/netsuite

Search only fields are not added to an upsert/add payload

Whoops. When defining the initial list of search_only_fields, I manually compared the fields of TransactionSearchRowBasic to the fields of Invoice and skipped any that existed on the underlying Invoice record, but other_ref_num must have slipped by.

I opened #487 as a quick fix while we discuss a long term fix.

I had a hunch this might arise, but figured it'd be once a shared concept was extracted for TransactionSearchRowBasic that could be shared amongst multiple records (ie. Invoice, CreditMemo, etc.).

What you're describing could work, but then there's still an issue if fields happens to be called after search_only_fields, right? We'd maybe want to update the field logic too to error if you're passing a name that was already included as a search_only_field.

I wonder if part of the problem is that behind the scenes search_only_field also calls field. Maybe field needs to be split up between appending to the list of fields and defining the reader/writer methods, the latter of which likely being the only part search_only_field cares about.

Let me take a deeper look at the code and see where the list of fields is used, expecting to include both read_only and search_only and see if it'd make sense that fields only had the standard fields, not also including the read_only and search_only fields.

iloveitaly

comment created time in a month

PR opened NetSweet/netsuite

Fix standard fields mistakenly included as search only fields

This prevents the fields from being included when pushing data to NetSuite.

Discussing a longer term fix in #486.

+8 -8

0 comment

4 changed files

pr created time in a month

create barnchcgunther/netsuite

branch : fix-search-only-fields

created branch time in a month

create barnchcgunther/rails

branch : av-select-optgroup-html-attrs

created branch time in a month

PR opened rails/rails

Add support for HTML attributes of optgroups to select helper

PR #11517 updated grouped_options_for_select to allow passing HTML attributes of the optgroup as the last element of each array, which is called internally by select when it detects grouped choices.

However, the select helper detected grouped choices by seeing if the last element is an Array, meaning if you passed a hash of HTML attributes, it would no longer treat the choices as grouped. This conflicted with grouped_options_for_select, which assumes the individual options are the second element, not the last element.

Now there's agreement between select and grouped_options_for_select in expecting the individual option choices to be the second element, allowing the hash of HTML attributes to exist as the last element and properly trigger grouped options.

Since this mismatch existed since v4.1 (when #11517 was merged), if this can be backported to at least v6.1, that'd be much appreciated to avoid having to wait for v7.0 to be released to take advantage of.

Thanks!

+28 -1

0 comment

4 changed files

pr created time in a month

PR opened NetSweet/netsuite

Explain search only fields in Readme

Attempt to document #483.

I wasn't sure how best to convey this given it affects consuming the search results, not performing the search itself. It should also be unsurprising that you'd access these search-only fields the same way you'd access regular or read-only fields.

Had we buried these search-only fields in custom fields, like #426 first attempted, then I'd find that more surprising and warranting clearer documentation.

+4 -1

0 comment

1 changed file

pr created time in a month

push eventcgunther/netsuite

Chris Gunther

commit sha 3bdecfea07800dd3e9e3d91d45d0fb24e8e31d75

Explain search only fields in Readme Attempt to document #483. I wasn't sure how best to convey this given it affects consuming the search results, not performing the search itself. It should also be unsurprising that you'd access these search-only fields the same way you'd access regular or read-only fields. Had we buried these search-only fields in custom fields, like #426 first attempted, then I'd find that more surprising and warranting clearer documentation.

view details

push time in a month

pull request commentNetSweet/netsuite

Introduce search only fields

Thanks for the quick merge!

cgunther

comment created time in a month

delete branch cgunther/netsuite

delete branch : search-only-fields

delete time in 2 months

delete branch cgunther/netsuite

delete branch : support-saved-search-custom-fields

delete time in 2 months

pull request commentNetSweet/netsuite

Action `get_all` return errors

Speaking mainly from the search scenario I provided above, exceptions would be fine. In my case, I'm throwing an exception anyway when the search returns false, so having the gem throw it itself, plus with details of the exact error, would save me a step of having to check for a false return value.

I think #405 could be a good basis, potentially having a generic error class, then on a case-by-case basis introduce more specific classes (ie. PermissionError) if they might be handled differently on the application side.

I also think #405 does a better job of addressing the problem at the response, rather than in the action class method, which might require repeating the handling for each action implementing a class method.

freezepl

comment created time in 2 months

pull request commentNetSweet/netsuite

Support non-record field results in saved search responses

I'd agree, this is predominantly addressed by 676a618.

davidlaprade

comment created time in 2 months

PR closed NetSweet/netsuite

Support non-record field results in saved search responses - Revised

This is a continuation of #426, addressing some snags I had using it to address a similar problem (https://github.com/NetSweet/netsuite/pull/426#issuecomment-778261253). Thanks @davidlaprade for the great starting point.

internal_id and external_id are now extracted from the search result to the record.

For API versions 2013.2 and newer, the non-standard fields returned in search are added as custom fields on the record, using the field name as script_id.

In wrapping this up, I'm noticing that both the real custom fields and the non-standard search result fields wrap their value in a searchValue element, however typically for custom fields, it seems to be wrapped in a value element, which the record then defines a helper method to access: https://github.com/NetSweet/netsuite/blob/438c233fc0ede0acbeb7f9fbe8c9d8004fb4654a/lib/netsuite/records/custom_field.rb#L17-L19

As this PR stands now, you'd access a non-standard search result field (or custom field) via: my_record.custom_field_list.my_custom_field.attributes.fetch(:search_value). However, after a typical get action, you'd access the same custom field via my_record.custom_field_list.my_custom_field.value. This doesn't appear to be a regression due to this PR, just an existing issue that may be surfacing now. When dealing with search results, would it make sense to copy the :search_value attribute to :value to ease using the same #value helper?

I'm still new to NetSuite so I'm not sure if I'm overlooking something here.

+1791 -4

3 comments

5 changed files

cgunther

pr closed time in 2 months

pull request commentNetSweet/netsuite

Support non-record field results in saved search responses - Revised

Superseded by #483.

cgunther

comment created time in 2 months

PR opened NetSweet/netsuite

Introduce search only fields

When performing a search, there's additional columns that can be requested that aren't normally on the record. Previously such columns were not accessible via this gem's search results.

Now these columns can be accessed just as you'd access a regular field or read only field.

Starting with InventoryItem and Invoice.

Ultimately, these are fields of the ___SearchRowBasic (ie. ItemSearchRowBasic and TransactionSearchRowBasic), so eventually it may be wise to extract a module encapulating those SearchRowBasic's and include that in the relevant records to avoid duplication of search only fields across multiple records (ie. Estimate, SalesOrder, Invoice, CreditMemo, etc.) that all utilize the same SearchRowBasic.

This is a second attempt at #470, which itself was a second attempt at #426.

+409 -1

0 comment

9 changed files

pr created time in 2 months