Opened 16 years ago
Closed 16 years ago
#4400 closed defect (fixed)
billing / internal state changes but it shouldnt
Reported by: | Steffen Lindner | Owned by: | Russ Tyndall |
---|---|---|---|
Priority: | normal | Component: | TimingAndEstimationPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
We set permissions in the way that only a special role can modify/see the billing/internal checkboxes. But if a "normal" user changes a value of a ticket (e.g. comment,keywords..) the billing/internal value gets changed (if it is unset it gets set).
We use this version: "SVN Trac0.11 branch With Permissions EXPERIMENTAL"
Attachments (0)
Change History (8)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
Wait... so how did you configure this?
It sounds like those fields are being removed from the form, which when they dont show up in the form post would cause their values to be reset (due to the fact that checkboxes that are not checked, are not submitted). Essentially by removing them from the form you are not checking them. What should happen is that they should be replaced with a hidden field, or possibly stored in session and retrieved from there (so that the user couldnt just change the hidden value).
Once I see the config you are using to get this to happen, I might be able to help.
Thanks,
Russ
comment:3 Changed 16 years ago by
Hi Russ,
thanks for the answer.
In trac.ini we added this custom ticket fields:
[ticket-custom] billable = checkbox billable.label = Billable? billable.order = 3 billable.value = 1 internal = checkbox internal.label = Internal? internal.order = 5 internal.value = 0
For customers we created the permission role_customers. We dont granted this role one of the TIME permissions.
Your description makes sense to me, but how implement it?
Thanks, Steffen
comment:4 Changed 16 years ago by
I actually need your configuration for permissions, not the custom fields (all the rows in the [field settings] section of the config).
The easiest way, if you are not too concerned about people trying to "hack" their way inside is to use 'hide' or 'disable' instead of 'remove', as the action of the permission. Otherwise we would need to do some more serious hacking to prevent the ability of people to change the hidden fields with crafted form posts.
comment:5 Changed 16 years ago by
Hi Russ,
heres my field_settings: [field settings] fields = billable, totalhours, hours, estimatedhours, internal billable.permission = TIME_VIEW:hide, TIME_RECORD:hide totalhours.permission = TIME_VIEW:hide, TIME_RECORD:hide hours.permission = TIME_VIEW:hide, TIME_RECORD:hide estimatedhours.permission = TIME_VIEW:hide, TIME_RECORD:hide internal.permission = TIME_RECORD:hide, TIME_RECORD:hide
I tried your suggestion, but it wont work ;( Something i forgott?
Thx for the help Steffen
comment:6 Changed 16 years ago by
i still stuck with this problem. You found time to look into it?
Steffen
comment:8 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Sorry, i missed this comment when it came through: Replying to anonymous:
Hi Russ,
heres my field_settings: [field settings] fields = billable, totalhours, hours, estimatedhours, internal billable.permission = TIME_VIEW:hide, TIME_RECORD:hide totalhours.permission = TIME_VIEW:hide, TIME_RECORD:hide hours.permission = TIME_VIEW:hide, TIME_RECORD:hide estimatedhours.permission = TIME_VIEW:hide, TIME_RECORD:hide internal.permission = TIME_RECORD:hide, TIME_RECORD:hide
I think I got this worked out, please let me know if you continue to have problems. Sorry for the delay
busy at the moment, but I will attend to this as soon as I can