Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(request): update a request #93

Merged
merged 5 commits into from
Dec 20, 2024
Merged

Conversation

Lelievre-david
Copy link
Contributor

No description provided.

@Lelievre-david Lelievre-david merged commit f524e80 into master Dec 20, 2024
6 checks passed
@Lelievre-david Lelievre-david deleted the feat/update-requests branch December 20, 2024 10:37
Copy link
Member

@Tao-Galasse Tao-Galasse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌 👏

Comment on lines +53 to +54
plant_attributes_from_params(@request)
if @request.update(request_params)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

En mettant les instructions dans cet ordre, on peut s'exposer à un petit souci de cohérence.
La première méthode appelée, plant_attributes_from_params, regarde si un ID est passé en paramètre, et assigne les champs plant_stage_name et plant_name si c'est le cas.

Puis, la méthode update assigne tous les paramètres passés par l'utilisateur ; dont les fameux plant_stage_name et plant_name.

Ce qui veut dire que dans l'idée, la méthode plant_attributes_from_params peut ici être overridée par les paramètres passés par le front, et donc créer des valeurs "illogiques" (par exemple, si passe l'id d'une rose mais je mets en dur que le nom est une tulipe ; et ça sera enregistré tel quel dans la bdd).

En inversant l'ordre d'appel des méthodes, on évite cette potentielle "faille" :)

Suggested change
plant_attributes_from_params(@request)
if @request.update(request_params)
@request.assign_attributes(request_params)
plant_attributes_from_params(@request)
if @request.save

(si tu regardes bien, c'est d'ailleurs bien dans cet ordre que sont appelées les méthodes dans le create, ou qu'elles l'étaient dans la méthode update d'origine, qui a récemment été supprimée dans une autre PR)

Comment on lines +32 to +39
def update?
if record.request_distributions.exists?
record.errors.add(:base, 'cannot update a request with associated request distributions')
false
else
true
end
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok pour la logique 👌 si on veut l'écrire de manière un peu plus "rails-ish" et concise, ça pourrait donner quelque chose comme ça :

Suggested change
def update?
if record.request_distributions.exists?
record.errors.add(:base, 'cannot update a request with associated request distributions')
false
else
true
end
end
def update?
return true unless record.request_distributions.exists?
record.errors.add(:base, 'cannot update a request with associated request distributions')
false
end

Comment on lines +279 to +280

request.reload
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vu qu'ici on n'utilise pas l'objet request plus bas, on n'avait pas spécialement besoin de le reload :)

Suggested change
request.reload

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants