BryanJBryce
Resources involved are Employee, Shift, and EmployeeShift
Employee and shift are related many_to_many, through EmployeeShift, however, since an employee can clock in and out multiple times during an shift EmployeeShift has it’s own id and isn’t unique by pairs of Employee and Shift ids:
attributes do
uuid_primary_key :id
attribute :in_at, :utc_datetime_usec, allow_nil?: false
attribute :out_at, :utc_datetime_usec
create_timestamp :created_at
update_timestamp :updated_at
end
relationships do
belongs_to :employee, PointOfSale.Accounts.Employee do
api PointOfSale.Accounts
allow_nil? false
attribute_writable? true
end
belongs_to :shift, PointOfSale.Stores.Shift do
allow_nil? false
attribute_writable? true
end
end
Additionally EmployeeShifts have a custom primary create action called start that takes arguments of employ_id and shift_id and set’s the start time:
create :start do
primary? true
accept [:employee_id, :shift_id]
argument :employee_id, :uuid, allow_nil?: false
argument :shift_id, :uuid, allow_nil?: false
change set_attribute(:in_at, DateTime.utc_now())
change set_attribute(:employee_id, arg(:employee_id))
change set_attribute(:shift_id, arg(:shift_id))
end
When I start a new Shift I want to be able to pass an array of Employee ids to manage_relationship so that the custom start create function is called on EmployeeShift so that the included employees are clocked in automatically as the shift starts:
Shift
has_many :employee_shifts, PointOfSale.Stores.EmployeeShift
many_to_many :employees, PointOfSale.Accounts.Employee do
api PointOfSale.Accounts
through PointOfSale.Stores.EmployeeShift
join_relationship :employee_shifts
end
create :start do
accept [:till_id, :employee_ids]
argument :till_id, :uuid, allow_nil?: false
argument :employee_ids, {:array, :uuid}, allow_nil?: false
change set_attribute(:start_at, DateTime.utc_now())
change set_attribute(:till_id, arg(:till_id))
change manage_relationship(:employee_ids, :employee_shifts, type: create)
end
However, when I attempt to create a new Shift via this action I get an error saying that the required arguments of shift_id and employee_id for EmployeeShift are missing.
The shift_id should come from the shift that is created just before running the manage relationship. And I thought I would be accepting employee_ids via the manage_relationship function.
I see that I can pass a map instead of a list of ids, and maybe that is the way, but that doesn’t solve the passing in of the shift_id that I don’t have since it get’s created.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










Showing Posts 1 to 10- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (newest first)
zachdaniel
Hmm…this rings a bell on a bug that was fixed in the not too distant past. How up to date is your ash version?
BryanJBryce
OK, updated everything, still no luck:
zachdaniel
ah, okay interesting. Sorry, didn’t notice this until now.
Try this:
BryanJBryce
That solves the
employee_idBut not the
shift_idBryanJBryce
I’m wondering if I even need the
many_to_manyat this point because the join table now has its own attributes and id, so should it really be modeled that way? I’m going to see if it changes anything. I don’t expect it to since the function is operating on thehas_manyrelationship.BryanJBryce
Yeah, that didn’t change it. I wonder if it is because
EmployeeShiftdoesn’t useshift_idoremployee_idas primary keys.BryanJBryce
Same result.
zachdaniel
Ah, okay I think its because its using the primary create action on the join resource which you’ve configured with required arguments.
zachdaniel
You’ll need to point it at a different create action and/or make those arguments optional (because
manage_relationshipwrites to the attributes, it doesn’t set arguments).BryanJBryce
Ah, I see, lemme throw in new action in there. Does it always use the primary action or is there a way to specify?