Closed kvdmolen closed 9 years ago
The code defines delegation as:
local delegated = app.session.member and app.session.member:has_voting_right_for_unit_id(issue.area.unit_id ) and issue.member_info.first_trustee_id and issue.member_info.own_delegation_scope == "issue"
Here, issue.member_info.own_delegation_scope == "unit"
. That is, delegation happened at the unit level, not the issue level. So the above test is failing and that's why you're not seeing the class added.
This "delegation scope" (I think) is necessary because delegation can happen at the issue, unit, area, etc levels.
Not sure what the change should be here, perhaps just disregard scope?
Hmm, I see. Let's be careful here, would not disregard as it might have impact anywhere else..
Is this variable "delegated" not defined in different places? So on the "unit" page it is defined as .. == "unit" ?
On the original page I do see the delegation-html in the breadcrumb, so there is some place it is defined correctly..
This code base is pretty bizar.. Sorry buddy :)
On Monday, April 20, 2015, nktc notifications@github.com wrote:
The code defines delegation as:
local delegated = app.session.member and app.session.member:has_voting_right_for_unit_id(issue.area.unit_id ) and issue.member_info.first_trustee_id and issue.member_info.own_delegation_scope == "issue"
Here, issue.member_info.own_delegation_scope == "unit". So the above test is failing and that's why you're not seeing the class added.
This "delegation scope" (I think) is necessary because delegation can happen at the issue, unit, area, etc levels.
Not sure what the change should be here, perhaps just disregard scope?
— Reply to this email directly or view it on GitHub https://github.com/Socioneers/LiquidVoting/issues/62#issuecomment-94504859 .
www.socioneers.com
Yes, on the what can I do sidebar, there is code like this:
if issue.member_info.own_delegation_scope == "unit" then
ui.heading{ level = 3, content = _"You delegated this organizational unit" }
elseif issue.member_info.own_delegation_scope == "area" then
ui.heading{ level = 3, content = _"You delegated this subject area" }
elseif issue.member_info.own_delegation_scope == "issue" then
ui.heading{ level = 3, content = _"You delegated this issue" }
end
So I guess what we need to know here is when do you want the .delegated
class added - when the issue is delegated, the unit, or both? Maybe a different class depending on the delegation?
OK, I think we're mixing the Sidebar and the Breadcrumb.
Breadcrumb:
There is always the unit
then the area
then the issue
in the breadcrumb. My preference would be to have a .delegated
class on the level which is delegated AND all afterwards. So, if the area
is delegated, both the <li class="area">
and the <li class="issue">
will get .delegated
.
Sidebar:
On the index-page and the unit-page, there is the "menu" with:
unit
- subject area 1
- subject area 2
Here, only add the .delegated
at the element which is actually delegated.
For the buttons ("change/revoke issue delegation") I'm not sure actually, I think these buttons are specific to which part of the chain is delegated, so that should perhaps explain your first finding.
On an issue page, if the user has delegated the issue, the original breadcrumb had a
<a class="delegation_info">..</a>
in the last li element (<li class="issue">
).I think this is a duplicate, but if that delegation
<a>
is/was there, theli
should have an additional class.delegated
so it becomes<li class="issue delegated">