#jessa-terminal-configuration
1 messages ยท Page 1 of 1 (latest)
We have lots of configuration objects, which one are you referring to?
sorry, the terminal configuration that you can assign to locations
jessa-terminal-configuration
So yeah this is a property. It maps to what's configured as the default in the Dashboard. You can't set that to a different one
so i can create a configuration via the api, then i have to go in the dashboard and set it as the default?
no
you create one in the API, and it won't be the default and that's it
if you want to change the default you have to do it manually in the Dashboard
sorry, but this is confusing me a little:
"if you want to change the default you have to do it manually in the Dashboard"
where can i do it manually in the dashboard?
ultimately i'm trying to set a configuration with tipping turned on as the default
i understand i can't change which configuration is the default, but i guess i will try to get the default configuration and add tipping to it instead of creating a custom one
hum you're righ, let me check. Sorry today is a weird day and I'm off my game
no worries
trying for a bit
okay so I tried, you can use the List API https://stripe.com/docs/api/terminal/configuration/list to find the default one and then you can update it
got it, thanks
sorry for the confusion earlier!
usually when we have an "is default" concept it's because there's a clear Dashboard UI for this ๐
no worries. seems you can't set the tip configuration anywhere in the dashboard either, so i'm guessing this isn't a widely used feature yet
yeahhhhhhh still it feels like it should be, and per location.
per reader would be best IMO, but i realize that doesn't work with the paradigm. i'm working with a movie theater that needs tips at the bar and concessions, but not in the box office window
but earlier you told me i can create separate locations in the same physical address, so that's what i'll do
yeah I think this is the perfect example of separate locations with different default configs
although per reader seems like a common use case (thinking of a grocery store that needs tips at the sandwich counter, but not at regular checkout)
seems like locations could be named to groups or something, to make it seem less tied to the physical address
right. but even that seems a little wrongly named, since it's not even a "location" that dictates using the same config.
it made sense when the only thing in the config was the splash screen, but now that tipping is part of the config, that has nothing to do with location, just the use case for the readers. so i'd call it group or subclass or something. anyway i think i can figure this out now, thanks for the help
yeah that's fair
i take that back, it's reasonable to call it sublocations, if you want to say the location inside the location, like bar or sandwich counter. so i agree with you. and you're busy, so i'll stop wasting your time chatting about semantics now ๐ thanks again for your help
yeah I think you want "groups of readers" where Location is just one of the "grouping criteria"