WIP: Refonte de la gestions des clubs #861
No reviewers
Labels
No labels
devtype -- backend
devtype -- docs
devtype -- frontend
devtype -- user interface
difficulty -- easy
difficulty -- hard
difficulty -- normal
Doing
domain -- bda
domain -- bds
domain -- cof
domain -- core
domain -- kfet
Good first issue
priority -- high
priority -- low
priority -- medium
priority -- staff-wanted
status -- development
status -- discussion
status -- need review
status -- production
status -- ready to merge
status -- todo
To Do
type -- bug
type -- hygiene
type -- improvement
type -- new feature
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: DGNum/gestioCOF#861
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "gestion-clubs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
478e0d5d07
to11aaef5f87
user.profile.is_buro
est plus adapté queuser.is_superuser
lorsqu'il s'agit d'accès, le buro n'est pas superuser@ -17,0 +38,4 @@
class ClubBudgetLine(models.Model):
label = models.CharField(_("libellé"), max_length=1000, unique=True)
vraiment unique ? Ça veut dire que deux clubs différents (au hasard hackens et pls) ont pas le droit de mettre une ligne "Scotchs" (ou le même clubs plusieurs fois)
si c'est pour primary key, une index sequence me parait bien mieux.
oui lol
@ -0,0 +15,4 @@
is_archived=False
).values("name", "id")
if self.request.user.is_superuser:
user.profile.is_buro
me parait plus adapté@ -0,0 +55,4 @@
def dispatch(self, request, *args, **kwargs):
if (
not self.request.user.is_superuser
user.profile.is_buro
me parait plus adapté11aaef5f87
toeb548f7d6c
eb548f7d6c
to52817cae7c
52817cae7c
to13d7332903
Il y a des problèmes d'installed apps entre gestiobds et gestiocof, qui font conflit, je fait une review plus complète quand c'est réglé (ptet que je le ferai). La solution la plus simple me simple de se déplacer, pour que se soit l'app "cof-clubs"
@ -34,6 +34,7 @@ app_dict = {
"bda": "gestion/bda/",
"petitscours": "gestion/petitcours/",
"events": "gestion/event_v2/", # the events module is still experimental !
"clubs": "gestion/budget/",
Même si c'est le truc principale sur lequel on travail actuellement, je suis pas sûr que l'app serve uniquement pour les budgets, elle pourrait servir de base de vérité pour les clubs (et respoclubs) à terme.
Je serai plus d'avis de mettre "gestion/clubs".
Totalement d'accord
@ -53,6 +54,7 @@ pkgs.mkShell {
configparser
django-autocomplete-light
django-bootstrap-form
django-bulma-forms
faudrait aussi l'ajouter dans le
requirements-prod.txt
(non-urgent)C'est pas publié dans pypi
Dans ce cas il faut un truc dans le readme pour avoir le paquet sans nix. Je veux pas que les gens galère à avoir un env de dev sur gestiocof sans nix à cause d'une dep
c964f25182
to14a66c9939
ec53307901
to7400b9da7d
7400b9da7d
to2316cd3d72
2316cd3d72
toe1a62e91f7
e1a62e91f7
tocc97baad63
e0ca0799de
to0e5fd1d790
Still TODO:
@ -0,0 +11,4 @@
class Meta:
model = ClubBudgetLine
fields = ["label", "amount", "date"]
widgets = {"date": forms.DateInput(attrs={"type": "date"}, format="%Y-%m-%d")}
Le
format="%Y-%m-%d"
me plait, mais il a pas l'air de marcher (même quand je l'edit dans l'inspect)Tu as quoi comme navigateur ? moi ça marche chez moi
Normalement
input type="date"
est bien supporté sur la plupart des navigateurs@ -0,0 +30,4 @@
<div class="navbar-dropdown is-right">
<div class="dropdown-content">
<form class="navbar-item" action="{% url "cof-logout" %}">
{% csrf_token %}
il faut suppr ça, ça fait un truc bizarre quand on déco sinon.
Je crois c'est pas ça. En mettant des a le comportement change pas. C'est juste la logoutview qui est pétée j'ai l'impression. Le formulaire est correct pour se protéger des csrf, cf https://docs.djangoproject.com/en/4.2/topics/auth/default/#django.contrib.auth.views.LogoutView (la deprecation notice)
@ -0,0 +42,4 @@
<div class="navbar-item">
<div class="buttons">
<a href="{% url "cof-login" %}" class="button is-light">
<span>{% trans "Se connecter" %}</span>
On a des page là dedans qui seront pas en
@cof_required
(ou@buro_required
) ?Pour l'instant oui. Mais en vrai on peut mettre toutes les pages en login required
Même en login required, cet partie sert pas. Il faut des pages sans login pour que se code s'active
oui tu as raison
@ -0,0 +14,4 @@
{% empty %}
<div class="tag cell is-warning">Ce club n'a pas de respo déclaré</div>
{% endfor%}
</div>
Un form agréable ici pour ajouter des respo si buro serai sympa, dans la catégorie des QoL accessoire.
Oui c'est dans les dernières features qui manquent. Mais je pense faire un clean up du code avant. Ce sera probablement le truc que je vais dev en dernier
@ -0,0 +4,4 @@
app_name = "cof_clubs"
urlpatterns = [
path("club/", views.ClubListView.as_view(), name="club-list"),
Je serai plus d'avis de mettre l'url "/", étant donné que c'est la page principale du module.
@ -0,0 +40,4 @@
success_url = reverse_lazy("cof_clubs:club-list")
class ClubListView(LoginRequiredMixin, TemplateView):
CofRequiredMixin
au lieu deLoginRequiredMixin
, cette page s'addresse aux adhérentsAlors il y a une vrai discussion d'implem à avoir. En particulier si tu es respo de club pour l'instant on ckeck pas ton adhesion. J'ai pris ce comportement pour pas se retrouver avec des situations étranges à la rentrée et une imposssibilité pour les clubs de consulter leur budget tant que le respo n'a pas adhéré ce qui est un peu une anti feature
@ -0,0 +110,4 @@
)
.prefetch_related("club__respos", "club__budget_managers")
.order_by(
"accounting_period__is_archived", "accounting_period__name", "date"
Ça sert à rien de trier par
accounting_period__is_archived
, tu as filter pour avoir uniquementFalse
@ -0,0 +121,4 @@
"label",
"id",
"posted",
"accounting_period__is_archived",
Idem, sert pas d'en parler
@ -0,0 +133,4 @@
s += line["amount"]
line["can_edit"] = self.request.user.profile.is_buro or (
not line["posted"]
and not line["accounting_period__is_archived"]
line["accounting_period__is_archived"] == False
Pourquoi ?
C'est une affirmation, pas une propal de réécriture
#861 (comment)
@ -0,0 +144,4 @@
return ctx
class BudgetLineAccessMixin(AccessMixin):
Met ça dans un fichier
decorators.py
s'il te plait, comme c'est fait pourCofRequiredMixin
ouBuroRequiredMixin
e72c64ec3a
toe4d591a6ea
9eab39d9c1
to56adc30794
56adc30794
to8fb4bd20c7
d6daeec78a
to4c52b62d2a
88d6470151
to20d30c8ebf
20d30c8ebf
to44f8de0e67
44f8de0e67
toeab095aa2f
eab095aa2f
to847b97030e
847b97030e
toccab227042
ccab227042
to8db6c6f012
8db6c6f012
to5e72c49eaa
5e72c49eaa
to40d68bf622
40d68bf622
to6c08023c05
6c08023c05
to94ebd5cb28
94ebd5cb28
tof58555e1ec
f58555e1ec
to44e06f4271
44e06f4271
tofdf2e2cee4
fdf2e2cee4
tof3cd729847
f3cd729847
to80eb058f58
80eb058f58
to58d55c4134
58d55c4134
toa75d448016
a75d448016
to8d49006d2d
8d49006d2d
tof6d45355c5
f6d45355c5
tof47bc19121
f47bc19121
to7cf79022b9
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.