I am using Easypost and creating the shipment by passing from_address, to_address, parcel, customs_info, carrier_accounts, options. The shipment got created successfully.
And at the time of buying the label(of this shipment), I would like to include more options. Is there any possible way to update the options at the time of buying the label?
Codebase: Nodejs
With the EasyPost API once a shipment object is created there isn't a way to modify the options on the shipment. What you'll need to do instead is create a new shipment with the options set the way you'd like. Since you haven't bought the shipment yet it won't cost you any extra either.
You can always email their support team (support at easypost dot com)
Related
I'm using finite machine to handle the state of Projects. Each project belongs to a Category and each category has many Steps.
Now I'd like to define in my ProjectStateMachine the next event which transits a project to the next steps according to its current state and category of belonging.
For instance, let's assume I have the "new lab" project (in the submitted state) associated with the equipment category. The equipment category has ['submitted', 'started', 'completed'] steps.
When the next event happens for the new lab project, its state becomes started and then when the next event happens again, the project goes in the completed state.
Is there a way to achieve so?
I'm unfamiliar with that specific gem (more on that later), but I would think you could do something like:
events {
self.category.steps.each_cons(2) do |set|
event :next, set[0].to_sym => set[1].to_sym
end
}
But with that said, the gem you referenced has not been updated in over a year. I'd recommend going with something more recent such as this (if you're using ActiveRecord which is based upon the state-machines gem). This last link takes you to a specific section on dynamic definitions, which will certainly give you what you want.
Cheers
I'm looking documentation/tips on importing data from an external API.
I'm building a website where users can add a company to their profile. However, I want people to be unable to create duplicate companies.
Therefore I want to call upon data from the official government API to verify the existence of the dossier integer by matching it to the integer entered on the form.
Any suggestions/explanations/tips are welcomed. If I find the solution I will obviously share this here.
Thanks in advance,
Julian
You can add a unique constrain to the name of the company, so you avoid duplicates
In Company.rb you can add the following validation:
validates :name, uniqueness: true
You also can use find_or_create_by like this to avoid duplicates
Company.find_or_create_by(first_name: 'company_name') do |company|
company.location = 'Wherever'
end
Here you are saying: Find the first company named 'company_name' or create a new one with a different location.
References:
reference for model validations
reference for find_or_create_by
We are exploring using the flipper gem (https://github.com/jnunemaker/flipper) to gate who sees new features. In one of our first tests, we want to show a specific feature to only the first X users that see a banner promoting it.
We looked at using a percentage, but the business is very specific on the number, and also wants to reach that number right away, then disable the feature for all other users, without disabling it for those that saw it first. Using a percentage, we weren't able to see a way to ensure the correct number would see it, and that everyone of the first x would see it.
Inside the gates/actor.rb, there is this:
enabled_actor_ids = value
which implies we could get the list of enabled ids, and perform a count on that, but we couldn't find whether or where that list may be exposed.
Since we are using the AR adapter as a trial, we instead created a scope on an actor object that joins to the flipper_gates table, but this feels extremely fragile and getting very much into the inner workings of the gem.
Any advice is greatly appreciated.
Nowadays you can do Flipper[:some_feature].actors_value.size, assuming you've configured your default flipper instance with Flipper.configure.
https://github.com/jnunemaker/flipper/blob/196946c63aee1eaa09fa25e945cdbff896fe71e5/lib/flipper/feature.rb#L258-L260
You should be able to accomplish this by programmatically turning the feature on for Individual Actors until an upper limit is reached.
IMPORTANT NOTE: according to the documentation:
The individual actor gate is typically not designed for hundreds or
thousands of actors to be enabled. This is an explicit choice to make
it easier to batch load data from the adapters instead of performing
individual checks for actors over and over. If you need to enable
something for more than 20 individual people, I would recommend using
a group.
Now that we've agreed that we want to move forward with this anyways.. Let's talk about implementation.
Enabling the feature for an actor
The first thing you need to do is to ensure that the actor (probably a User) responds to flipper_id and that the flipper_id is unique for every actor. Once that is set up, you should be able to simply do enable the feature for a user when they see the banner like this:
flipper[:stats].enable_actor user
Counting actors enrolled in a feature
Now, in order to determine if we should enable the feature for a user, we need to determine how many users have been enrolled in the feature.
To do this we can query the Gate directly:
Flipper::Adapters::ActiveRecord::Gate.where(
feature_key: "stats",
key: "actors"
).count
This will return a count of the number of actors enrolled in a feature.
How do we know that works?
Well, let's take a look at the gem.
flipper[:stats].enable_actor actually calls Feature#enable_actor with the user we passed in earlier (that responds to flipper_id) being passed in as the actor.
Next, Feature#enable_actor passes the actor into Types::Actor.wrap which creates a new instance of Types::Actor which checks to make sure the actor isn't nil and that it has a flipper_id and then sets two instance variables, thing which is set to the actor, and value which is set to the flipper_id of the actor.
Now that we have an instance of Types::Actor, we pass it into Feature#enable which looks up the gate which in our case would be a Gates::Actor instance. Finally we call enable on the adaptor (which in your case is ActiveRecord).
In Adapters::ActiveRecord.enable we first look at gate.data_type which in our case, is :set. From there we do:
#gate_class.create! do |g|
g.feature_key = feature.key
g.key = gate.key
g.value = thing.value.to_s
end
Where, as mentioned earlier, thing.value is the flipper_id. Bingo! #gate_class is the active record class responsible for the gates table and the default table name is "flipper_gates".
Now we know exactly what to query to get a count of the actors enrolled in the feature!
number_of_actors_enrolled_in_stats_feature = Flipper::Adapters::ActiveRecord::Gate.where(
feature_key: "stats",
key: "actors"
).count
I am attempting to use the ice_cube gem to set up a schedule for recurring shifts. What I am struggling with is the recurring events are not real instances of my model with an ID; I need to be able to reference each event to associate it with a shift_confirmation method (detailing things like the actual end time vs. the booked end time, whether the shift has been paid, etc.).
Where I'm struggling is that if I add an actual instance of my model, as opposed to a recurring instance, I will end up with both - the instance I can refer to with an ID, and also a recurring instance.
I have considered whether I can add an IceCube exception that removes a shift from the recurrence schedule each time a user wants to edit it (e.g. to mark it complete, paid, etc.), and create an instance of my model, but this seems very unclean - there must be a better way.
Is there any way to refer definitively to an specific event in an ice_cube recurring schedule, so that I can do things like mark it paid (which would be in an associated model)?
When you create an schedule, the schedule has an idea, probably you can use this in your structure.
I viewed this post, because i've a similar problem.
I've an table activities, with start-, end datum and duration and an related table schedule with the reference 'activity_id'. I didn't want to store the ice-cube to_yaml string, because I want the option to add 'closing dates' in the future on a central place, without parsing every record again.
If you show your structure, maybe I can be of some help.
Regards, sander
Check out the schedulable gem, it lets you persist event_occurrences in the database and let's your "schedule" edit only future occurrences.
We're working on a SaaS product that uses Payola to handle payment, and we'd like to add a referral promotion. Adding the coupon to the referee is simple enough (hidden field on the form with the coupon code), but there doesn't seem to be any obvious way of applying a coupon to an existing subscription.
I've checked the Payola source, and there doesn't seem to be any methods dealing with applying a coupon code to an existing subscription, just for a new one.
Can we just get the Stripe::Customer object and use this answer: How to Apply a Coupon to a Stripe Customer to apply the coupon? Will that mess up Payola at all?
Since the Payola stores the subscription details in its own table, it isn't sufficient enough to just update subscription on Stripe. Now, if we take a look at the subscription_controller.rb:28 we see what Payola itself does when new coupon is applied (you can apply a new coupon with Payola when changing the plan as can be indirectly seen from before_filter find_plan_coupon_and_quantity called also on change_plan method. The find_plan_coupon_and_quantity method leads to the call #coupon = cookies[:cc] || params[:cc] || params[:coupon_code] || params[:coupon]). What it does is that it calls Payola::ChangeSubscriptionPlan.call(#subscription, #plan) which again is declared in change_subscription_plan.rb:3 and calls another method retrieve_subscription_for_customer on the same file. This method is the key here as it retrieves the actual subscription from the Stripe and returns it. Here is that method for reference
def self.retrieve_subscription_for_customer(subscription, secret_key)
customer = Stripe::Customer.retrieve(subscription.stripe_customer_id, secret_key)
customer.subscriptions.retrieve(subscription.stripe_id)
end
After fetching the subscription it updated according to the new plan details and stored in Payola's own data structures in database.
After this long and exhausting investigation we can see that it should be suitable to update the Stripe manually and then apply same kind of update on Payola subscription as described above. So to answer your original question about messing Payola: Yes, it will mess Payola, but you can fix it manually by copying the code used by Payola itself to keep in sync.
Hope this helps you to achieve the desired functionality and at least directs you to correct direction.