model.relation.beforeAdd and model.relation.afterAdd events not called when using AttachOneOrMany::create()
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 1.5k
- Forks
- 246
- Avg merge
- 19h 2m
- Merged PRs (30d)
- 7
Description
Winter CMS Build
1.2
PHP Version
8.1
Database engine
MySQL/MariaDB
Plugins installed
No response
Issue description
Hi,
I was trying to debug it and, while reading the sources, I saw this and it doesn't feel right at first glance:
https://github.com/wintercms/storm/blob/374add95da31e6ba1ab4b07ac6d4f03fa85c2503/src/Database/Relations/Concerns/AttachOneOrMany.php#L153-L155
In my controller, I have something like:
$task->attachments()->create(['data' => $attachment])
However, even if attachments are properly attached to my model, model.relation.beforeAdd and model.relation.afterAdd events are not called because $sessionKey is obviously null.
P.s.
From the docs, it reads that is_public property must explicitly set when using the add method. However this condition seems to ensure that the correct value is properly set.
Alternatively, you can prepare a File model before hand, then manually associate the relationship later. Notice the
is_publicattribute must be set explicitly using this approach.
Any suggestion? Thank you as always.
Steps to replicate
- Setup an
$attachManyrelation. - Attach a file using
createmethod.
Workaround
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/Database/Relations/Concerns/AttachOneOrMany.php around lines 151-167, then reproduce the issue with an $attachMany relation and the create() call shown. Check how the relation events are handled when no session key is supplied; done means beforeAdd and afterAdd are called for attachments created through create(), with the documented is_public behavior preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- mariadb, mysql, php
- Domain
- backend, database
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100