[savannah-help-public] [sr #109694] replace SV_THEME cookie with db stored user preference

2019-06-19 Thread Peter Liscovius
Follow-up Comment #3, sr #109694 (project administration):

Yea, extra themes in addition to a default theme is not important.

Netherless it is still very confusing together with the SV_THEME cookies on
both domains savannah.gnu.org and savannah.nongnu.org
as each stores cookie in browser separate value for the duration of the
session.

Try:

1. Clear browser cookies (or retest later without clearing them in a second
test)
2. Login on savannah.gnu.org with login to 'brother nongnu' checked box. 
3. Go straight 'My Account Conf' https://savannah.gnu.org/my/admin/ (watch
gnu/nongnu)
4. Change theme dropdown, click 'Update'. (Looks ok, it looks like savannah,
also SV_THEME of savannah.gnu.org cookie changes to Savannah)
5. Follow link to the brother site, like clicking 'Get support' for going to
https://savannah.nongnu.org/support/?group=administration
   BAM! The savannah.nongnu.org shows a different theme and SV_THME cookie of
savannah.nongnu.org is the other theme name.
6. Click 'My Account Conf' https://savannah.nongnu.org/my/admin/ (watch the
diiference to point 3.!)
7. Change theme dropdown to 'DarkSlate', click .Update'. (Looks like
DarkSlate, SV_THEME of savannah.nongnu.org cookie changed to DarkSlate)
8. Click left bottom link 'Gnu Savannah' savannah.gnu.org .
   BAM! Then savannah.gnu.org shows not the DarkSlate, but the Savannah
theme.

As both sites use the same database, it is IMHO not necessary to set any
SV_THEME cookie or read any SV_THEME cookie, as the information can be read
from savane user database (and probably possible without the cost of an extra
sql query because user info must be read in any case from database?)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109711] PHP code style of savane

2019-06-19 Thread Peter Liscovius
URL:
  

 Summary: PHP code style of savane
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Wed 19 Jun 2019 09:02:37 PM CEST
Category: Savannah website
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Coding styles are different between programming languages, different between
companies, also different between communities of a programming language by
countries sometimes, and even change over time.

Netherless I want to point out some rules that SHOULD be applied to the PHP
code of savane when changing a file or writing a new .php file:

* Do not put any spaces between a function call and the opening parenthesis.
  It makes reading and searching sourcetrees easier (a grep -rin 'time(' would
not match 'Time to say goodbye.', but any variant of time( Time( tIME( ... 

This was the vote result for PSR-2:


function_space_after:
no: 22


Clearly.

* Always put the body following an *if* structure within curly brackets, even
if it just contains a single expression!
  Not putting curly brackets there is like laying hidden mines and provokes
hard to find bugs for any later person.
  I don't know why people still keep doing that evil shortcut. Maybe it is
from C-coders that used it 40 years ago to optimize their compiler that
couldn't optimize {} out when a single command follows? I don't know.

There is https://www.php.net/manual/en/control-structures.if.php , but that
guys are C-coders too. 
  For single expression if's there is the ternary conditional operator (but I
find it easier write and read read 'if ($x){ expression } else { expression }'
constructs) 
  'if ($x) ? expression : expression;'

This was the vote result for PSR-2:

+verbstim+
always_use_control_braces:
no: 3
yes: 19


Quite clearly.

* Please optionally put . in PHP comments only if it is *a full sentence*. I
even prefer not to put a . even for a single sentense in comment, but that is
not important.

* Do not indent curly brackets at nowhere spaces. Either align it 
  * vertical with the if/while/switch/for/..  
  * opening curly bracket at same line, ending bracket vertical aligned with
if/while/switch/for(...

The other whole bunch of coding styles are debatable, but these 4 are IMHO
important to follow.

General:

* Only change code that matches the commit message. Stick to an existing
coding style of a file. Keeps the changes to git commits small and makes
reviews/git history/git blame/ easier.

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

There is also PSR-2 https://www.php-fig.org/psr/psr-2/, but I would not fully
agree to that standard (See the quite diverting voting results at
https://www.php-fig.org/psr/psr-2/#a1-survey-data 
https://www.php-fig.org/psr/psr-2/

I disagree to that PSR-2 rule:

-verbatim+
indent_type:
tab: 7 (I prefer this as a user of also dumb/basic editors, navigation
easier)
2 spaces: 1
4 spaces: 14


The other rules of PSR-2 are either ok or I do not care of the flavor and can
adapt to it.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109696] markdown verbatim (for code snippets) does not respect white-space

2019-06-19 Thread Peter Liscovius
Follow-up Comment #5, sr #109696 (project administration):

Someone compared available webbrowser side based javascript syntax
highlighters.

They all work on code sections in the html content wrapped by pre-tags or
combinations of pre+code-tags.

https://webdesign.tutsplus.com/articles/25-syntax-highlighters-tried-and-tested--cms-23931


Here are some links for checking out if applicable and license.


https://github.com/syntaxhighlighter (MIT License)


https://github.com/PrismJS/prism (MIT License)


https://github.com/highlightjs/highlight.js (own license)


https://github.com/ccampbell/rainbow (Apache License 2.0)


https://github.com/google/code-prettify (Apache License 2.0)



https://sourceforge.net/projects/jush/ (LICENSE not set yet)
https://github.com/vrana/jush (LICENSE not set yet)

And then there are server side parsers, which are - ummh -  special:

There is Python Pygments and PHPygments
https://github.com/capynet/PHPygments (own license)
and seems to be wide adopted according to http://pygments.org/faq/ . So a
serverside syntax highlighting is possible. Maybe not applicable due their
license or require change license needed.

My experience with GeSHi (https://github.com/GeSHi/geshi-1.0 (GPL 2) and fork
https://github.com/easybook/geshi ) which is used by Dokuwiki and Flyspray:
Slow and not solid as I wish (slowiness mitigated by caching to file/database
unless origin content changes). Probably will replace it in future.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109696] markdown verbatim (for code snippets) does not respect white-space

2019-06-19 Thread Peter Liscovius
Follow-up Comment #6, sr #109696 (project administration):

There is also a project here on gnu.org: 

https://savannah.gnu.org/projects/src-highlite/

(I never tried or if applicable to savane.)

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109710] reduce visual noise of 'Assigned To' in support, tasks, bugs, .. table output

2019-06-19 Thread Peter Liscovius
URL:
  

 Summary: reduce visual noise of 'Assigned To' in
support,tasks,bugs,.. table output
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Wed 19 Jun 2019 04:56:34 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello Ineiev,

here a simple suggestion (hope you are not too upset from my comment in 
support #109696):

Remove the text 'None' from the output column 'Assigned To' (for instance
https://savannah.nongnu.org/support/?group=administration ) when there is no
one assigned to a support/task/bug/patch/cookbook .

This way it is much easier to see if someone is assigned to something or not.
The word 'None' does not add value compared to nothing but distracts from
absorbing information of the shown table.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109696] markdown verbatim (for code snippets) does not respect white-space

2019-06-19 Thread Peter Liscovius
Follow-up Comment #4, sr #109696 (project administration):

Hello Ineiev,

this is not solved yet.

It converts tabs to  too.

As the verbatim section is for nonmodifying code sections that can be copied
simple by selection areas with mouse for instance, I really suggest using the
pre tag and only cleanup for output with something like htmlspecialchars().

Using the pre tag here is better than p paragraph tag (semantic and by default
css of web browsers)

Please do not fiddle with the content inside the verbatim tag if possible.

As I suggested earlier, layout breaks by nasty long or height code sections
can be tamed by CSS.

If this is not convincing enough, take a look at other webbased trackers.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109708] savane db field user.user_name is not unique

2019-06-17 Thread Peter Liscovius
URL:
  

 Summary: savane db field user.user_name is not unique
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Mon 17 Jun 2019 02:57:41 PM CEST
Category: Savannah website
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On the demo database:


select count(*) c, user_name, group_concat(user_id) from user group by
user_name having c>1

+---+---+---+
| c | user_name | group_concat(user_id) |
+---+---+---+
| 4 | adamsmith | 92020,221,47304,72429 |
| 3 | andrewsmith   | 106582,94776,101723   |
| 2 | ashleymartinez| 107573,19373  |
| 2 | bridgetprice  | 20499,34106   |
| 2 | carlaellis| 75633,106150  |
| 2 | danielgoodman | 85516,87948   |
| 2 | daniellefox   | 88268,78669   |
| 2 | daviddavis| 59288,67101   |
| 2 | davidedwards  | 86993,93490   |
| 2 | edwardwatson  | 30052,19520   |
| 2 | jasonperez| 99065,28884   |
| 2 | jeffreyjordan | 92169,103404  |
| 2 | jessicaadams  | 92629,107211  |
| 2 | justinwang| 69330,73640   |
| 2 | kimberlyshaw  | 90478,95200   |
| 2 | kristenpeterson   | 61577,84354   |
| 2 | michellerodriguez | 58784,76762   |
| 2 | robertjohnson | 63228,93870   |
| 2 | robertwilliams| 32051,87132   |
| 2 | sarahhernandez| 13546,75041   |
| 2 | williamlopez  | 76170,40977   |
+---+---+---+





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109706] endless redirection loop in web.cvs.savannah.gnu.org

2019-06-12 Thread Peter Liscovius
URL:
  

 Summary: endless redirection loop in web.cvs.savannah.gnu.org
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Thu 13 Jun 2019 01:01:59 AM CEST
Category: Source code repositories - web browsing
Priority: 5 - Normal
Severity: 6 - Security
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

When

1. go to http://web.cvs.savannah.gnu.org/viewvc/
2. choose any project
3. sort by any header column link
4. click on top-left link '/' in the browser view

or simple visit

http://web.cvs.savannah.gnu.org/viewvc?sortby=date

an endless redirection loop happens.

http://web.cvs.savannah.gnu.org/viewvc?sortby=date

Only webbrowsers redirection limit stops it.
(in Firefox 67 about:config network.http.redirection-limit=20)

The http://web.cvs.savannah.gnu.org/viewvc/ says version 1.1.15 from 2012, the
current viewvc version is 1.1.27
https://github.com/viewvc/viewvc/releases/tag/1.1.27 . 

Maybe updating solves the problem? Debian packages are at least 1.1.26




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109705] make session cookies httponly

2019-06-11 Thread Peter Liscovius
URL:
  

 Summary: make session cookies httponly
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Tue 11 Jun 2019 07:33:46 PM CEST
Category: None
Priority: 5 - Normal
Severity: 6 - Security
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The session_hash and session_uid are not httponly, which means javascript
could read document.cookie

So easy fix might changing 

setcookie($name, $value, $expiration, $path, $domain, $secure);

to

setcookie($name, $value, $expiration, $path, $domain, $secure, true);

in frontend/php/include/session.php

see https://www.php.net/manual/en/function.setcookie.php

Also the session cookies are .savannah.gnu.org, not savannah.gnu.org, so any
subdomain tool has access to the session (I see it was intentional made, but
is it used yet anywhere?)

While savannah.gnu.org has content-security-policy default 'self' which makes
XSS harder, the subdomains like https://web.cvs.savannah.gnu.org have not, so
a XSS there could read document.cookie 

By setting the httponly option for session related cookies it would be a bit
harder to exploit a XSS bug.



___

File Attachments:


---
Date: Tue 11 Jun 2019 07:33:46 PM CEST  Name: savane_cookies.png  Size: 241KiB
  By: peterdd



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109704] remove textarea:hover from Savannah.css

2019-06-11 Thread Peter Liscovius
URL:
  

 Summary: remove textarea:hover from Savannah.css
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Tue 11 Jun 2019 07:12:29 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The current

textarea:hover {color:#ff;}

in css/Savannah.css is annoying.

It looks like all my text is spelled wrong (maybe it is ;-) ) as red is used
as color of errors of spellchecking tools
too.

I do not know what the original purpose of that css rule was. Maybe they
wanted highlight the current editing textarea. But for that case
textarea:focus would be more appropriate. 




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109702] install broken

2019-06-10 Thread Peter Liscovius
URL:
  

 Summary: install broken
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Tue 11 Jun 2019 06:22:31 AM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I tried following current
http://savannah.gnu.org/maintenance/RunningSavaneLocally/ instructions.


default: make[2]: Entering directory '/home/vagrant/savane/backend'
default: make[2]: *** No rule to make target 'export/sv_export', needed by
'all-am'.  Stop.
default: make[2]: Leaving directory '/home/vagrant/savane/backend'
default: Makefile:404: recipe for target 'all-recursive' failed
default: make[1]: Leaving directory '/home/vagrant/savane/backend'
default: make[1]: *** [all-recursive] Error 1
default: Makefile:450: recipe for target 'all-recursive' failed
default: make: *** [all-recursive] Error 1





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109699] get rid of splitleft-splitright wrapping divs on of my/admin/

2019-06-08 Thread Peter Liscovius
URL:
  

 Summary: get rid of splitleft-splitright wrapping divs on of
my/admin/
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Sat 08 Jun 2019 03:43:12 PM CEST
Category: Savannah website
Priority: 5 - Normal
Severity: 1 - Wish
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Problem: savane layout does not well adapt to different display resolutions.
The world today ranges from 320 CSS-pixel portrait mode on mobile phones like
iPhone 5 SE up to 15360x8640 (16K8K) displays.

This provides a starting mitigation solution for the 'My Account Conf' page:
The wrapping splitleft-splitright divs can be simply removed. Just remove the
calls of html_splitpage() in frontend/php/my/admin/index.php

So the main content of my/admin/ is displayed as a single column on small
mobile displays or browser viewports. But on larger displays it can be 2 or
more columns when the boxes .box has a
display:inline-block;vertical-align:top; and maybe set a max-width: (see
@media-queries)

Also then the span-clearr-wrappertag is not required anymore.

Also most of additional br-tags in frontend/php/my/admin/index.php are not
necessary. A visual spacer between boxes can be done by 


form#myconf .box{
 margin-bottom:1em;
}


or something like that.

The 'Delete Account' box can be put last outside of the whole form-tag as it
only leads to a separate page. 

BTW: Often an ancient float: misused for a page layout can be replaced by 


display:inline-block;
vertical-align:top;


that does not require extra html tags just for clearing
purposes.(clear:both/left/right;) 




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109696] markdown verbatim (for code snippets) does not respect white-space

2019-06-08 Thread Peter Liscovius
Follow-up Comment #2, sr #109696 (project administration):

> First, we want to wrap those verbatim elements at reasonable width --- if
they aren't, long lines break rendering of whole item. 

I do not think it is necessary to change the content except XSS filter before
output. CSS has ammunition to handle overlong nasty strings for output not
destroying the layout and preserving whitespace in code snippets: 


overflow-wrap:
(former word-wrap:) see
https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap

white-space:
overflow: (or overflow-x: overflow-y:)
hyphens:



example long word in a paragraph

blabla
x1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

example long word in code snippet


blabla
x1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789



I use currently 


word-wrap:anywhere;


for the whole comment/item text/

and 


overflow:auto;

for code section

> Then, it's desirable to make this work with CSS-unaware browsers as well.
??? example? 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15299] rename PERL to Perl in user skills

2019-06-06 Thread Peter Liscovius
URL:
  

 Summary: rename PERL to Perl in user skills
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Thu 06 Jun 2019 08:56:53 PM CEST
 Should Start On: Thu 06 Jun 2019 12:00:00 AM CEST
   Should be Finished on: Thu 06 Jun 2019 12:00:00 AM CEST
Category: None
Priority: 3 - Low
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

See also https://www.perl.org/about/style-guide.html

Probably just a 


UPDATE people_skill SET name='Perl' WHERE name='PERL';


and/or edit to db/mysql/table_people_skill.initvalues




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109696] markdown verbatim (for code snippets) does not respect white-space

2019-06-06 Thread Peter Liscovius
URL:
  

 Summary: markdown verbatim (for code snippets) does not
respect white-space
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Thu 06 Jun 2019 08:16:28 PM CEST
Category: Savannah trackers - bugs, tasks, etc.
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

spaces (single space, tabs, ..) are not preserved in output of savane markdown
_verbatim_ areas.

Easiest solution is to replace the p-tag within the blockquote-tag by a
pre-tag, that has CSS


display: block;
font-family: monospace;
white-space: pre;


by default in web browsers.

And then there is no need for putting extra br-tags there too.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[savannah-help-public] [sr #109693] Full Markup and Rich Markup help links replace editing page

2019-06-06 Thread Peter Liscovius
Follow-up Comment #3, sr #109693 (project administration):

Ok, let me explain my position deeper:

Imaging a user writes an item (bug, task, support, comment,..), took time to
formulate the problem, proof read and finally wants to add some markdown sugar
for formatting stuff. The helper link 'Rich Markup' is positioned very near
the input text area. What a user would expect?

I am sure most users are frightened to death seeing that all their work seems
immediatly lost and never will try to use again the markdown helper link for
fear loosing their work in future. Or even never participate again in projects
hosted by a savane / savannah.gnu.org due such bad experience.

In a try to revert a user _could_ use the *back button* of their browser, but
I know systems where that does not work. I also think that it is just a
convenience of todays web browsers to remember the input made on the previous
page. (have not verified it)

The quick fix target="_blank" was just a simple example how to avoid that.
BTW, I am not the only one that sees a problem with opening a help link
replacing same window:

https://www.standardaccesskeys.com/SAK2014/#spec


Access Key   ScopeLocation   Window/Tab
0 (zero) Page Help   New Window



But as I wrote, there are also softer CSS solutions to that problem that are
not such brutal as like opening a separate tab/new window:

Here is an example of how to implement a *CSS only* html tooltip that just
overlays, not loads another page.
I implemented that css only solution on bugs.flyspray.org for keyboard
shortcuts.

I use *s_* as id-prefix for storing a 'status' in a input checkbox and the
different labels toggle that status. The label tags MUST direct follow the
input tag  in code, but can appear everywhere visual on the page due CSS.

The HTML:


icon Rich Markup


close icon
The mdhelp content html



The CSS:

#mdhelplabel {cursor:pointer;padding-left:1em;}
#mdhelpclose {cursor:pointer;float:right; }
#mdhelp {
  display:none;
  position:fixed;
  z-index:100;
  background:#fff;
  border:1px solid #999;
  border-radius:10px;
  padding:10px;
  box-shadow:0 0 400px #000;
  top:50%;
  margin-top:-250px;
  height:520px;
  left:50%;
  width:300px;
  margin-left:-150px;
  box-sizing:border-box;
}
#mdhelpmodal {
  background-color: rgba(0, 0, 0, 0.3);
  display: none;
  height: 100%;
  left: 0;
  position: fixed;
  top: 0;
  width: 100%;
  z-index: 99;
  cursor:pointer;
}
#s_mdhelp {display:none;}
#s_mdhelp:checked ~ #mdhelp, #s_mdhelp:checked ~ #mdhelpmodal {display:
block;}


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15298] replace SV_THEME cookie with db stored user preference

2019-06-05 Thread Peter Liscovius
URL:
  

 Summary: replace SV_THEME cookie with db stored user
preference
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Thu 06 Jun 2019 03:14:59 AM CEST
 Should Start On: Thu 06 Jun 2019 12:00:00 AM CEST
   Should be Finished on: Thu 06 Jun 2019 12:00:00 AM CEST
Category: None
Priority: 3 - Low
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

My web browser is intentional configured to delete all cookies when closed.

This makes setting a theme cookie in savannah quite useless for such dudes
like me.

Also savannah.nongnu.org and savannah.gnu.org store each their own SV_THEME
cookie, so setting the theme on one site does not apply to the other site.

A solution to this would be storing the theme setting in a database field of
the user.

Also while watching the cookies in web develeoper tools I saw the SV_THEME
cookie was sometimes stored with different Domain range: 

Name Domain
SV_THEME .savannah.nongnu.org
SV_THEME savannah.nongnu.org





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15294] horizontal submenus not easy reachable with mouse (firefox)

2019-06-05 Thread Peter Liscovius
Follow-up Comment #5, task #15294 (project administration):

One more info:

The Gna.css theme does not have the 'gap experience', because it has an
additional 

.topmenuitemmainitem{
border: thin solid #b3e2e3;
}

that the default savannah has not.

That makes the li item hitarea a little bit bigger than 1em height so more
1.1em and so IMHO no gap.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15297] remove text-shadow from h1.prioxxxxx of base.css

2019-06-05 Thread Peter Liscovius
URL:
  

 Summary: remove text-shadow from h1.priox of base.css
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Thu 06 Jun 2019 02:17:12 AM CEST
 Should Start On: Thu 06 Jun 2019 12:00:00 AM CEST
   Should be Finished on: Thu 06 Jun 2019 12:00:00 AM CEST
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

The title with a text-shadow is harder to read and looks even more weired when
combined with other color themes than the default theme.

If a theme wants to style h1 heading in a weired way, they can do that in
their theme, but the text-shadow and color should not be in the base.css .
IMHO.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15296] Full Markup and Rich Markup help links replace editing page

2019-06-05 Thread Peter Liscovius
URL:
  

 Summary: Full Markup and Rich Markup help links replace
editing page
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Thu 06 Jun 2019 01:52:18 AM CEST
 Should Start On: Thu 06 Jun 2019 12:00:00 AM CEST
   Should be Finished on: Thu 06 Jun 2019 12:00:00 AM CEST
Category: None
Priority: 3 - Low
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

That is annoying when you type a task or comment and just want to view the
flavor of savannah markdown rules and bam! - page replaced.

A simple fix for that is a target="_blank" attribute of that links.

More fancy tooltips without opening a new tab/window are possible with pure
css too, but require change of markup too(1 input checkbox tag, 2 label tags,
1 div tag containing the markdown help info, and several css rules)




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15294] horizontal submenus not easy reachable with mouse (firefox)

2019-06-05 Thread Peter Liscovius
Follow-up Comment #4, task #15294 (project administration):

I vote against a default 'stone age menu'. 

What is against 'top:1em;' as quick fix?

BTW: li.topmenuitemmainitem{} has

float:left;
display: inline;

in base.css which results in that the div class="topmenu" has calculated
height 0.

Removing the float would give you back the defined background-color of the
Savannah.css in .topmenu{}






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15295] confusing savane savannah

2019-06-05 Thread Peter Liscovius
URL:
  

 Summary: confusing savane savannah
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Wed 05 Jun 2019 08:48:14 PM CEST
 Should Start On: Wed 05 Jun 2019 12:00:00 AM CEST
   Should be Finished on: Wed 05 Jun 2019 12:00:00 AM CEST
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

It is quite confusing on many levels for an outsider.

To my current understanding Savannah's software is called Savane, but when I
search savane in projects I only get 2 outdated failed rewrite attempts.

So it seems the project main page of Savane is
https://savannah.nongnu.org/projects/administration/

But then there are not only 3 versioning systems in use there: git,
subversion, cvs - they are also not in sync or lead to the real up to date
source:

In the 'Development Tools' section:

The first 'Git Repository' - 'Browse Source Repository'
http://git.savannah.gnu.org/cgit/administration.git
last edit was 2012!

Only when you click on 'Git Repository' leads to a page
https://savannah.nongnu.org/git/?group=administration
where is stated that there are 4 different git repositories for the same
software:

GNU Savannah
Sav!  (what is this???)
Savannah's Savane (whats the difference to GNU Savannah?)
Savannah external test suite (ok..)
So I have to clone all to see on which people really work?


Why not add some notes beside the source links in that they are outdated? Or a
comment beside the links in the Development Tools section?

Ok, finally I seemed to found the right and cloned it, but then:
file ChangeLog last entry is 2007-10-05. WTF?
Ok, I look into NEWS and there is: 2019-01-09 3.4 (ok, wipe sweat from
forehead :-)

Then there are 
grep -rin gna.org | wc -l
253

references to a mysterious domain gna.org that does not exist (anymore).



Then I tried http://savannah.gnu.org/maintenance/SavaneInABox/
, but the link to the box does not exist.

I had good experience using vagrant for local testing. Maybe provide a
Vagrantfile for easy tryout Savane?
- A vagrant base box
- some apt-get (as you prefer deb/ubuntulike distris)
- pull/clone savane
- some setup shell commands
- (re)start mysql + apache services
- done

I also detected some security issues with current savane. Where to report?




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #15294] horizontal submenus not easy reachable with mouse (firefox)

2019-06-04 Thread Peter Liscovius
URL:
  

 Summary: horizontal submenus not easy reachable with mouse
(firefox)
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Tue 04 Jun 2019 06:46:30 PM UTC
 Should Start On: Tue 04 Jun 2019 12:00:00 AM UTC
   Should be Finished on: Tue 04 Jun 2019 12:00:00 AM UTC
Category: System
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

There is a gap between the mouseover of a topmenu entry (like 'Tasks' and its
submenu entries, which results that the submenu disappears before able to hit
the submenu item. (or you are fast enough with mouse crossing the gap is not
detected.)

Removing the CSS top:1.1em; in ul.topmenuitemsubmenu{} of base.css seems to
mitigate that problem.

Experienced: Firefox 67 (macOS), otter-browser (webkit-backend 602.1)

No problem: Safari and Chrome (macOS)




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[Savannah-hackers-public] [task #6418] savannah login weired

2007-01-22 Thread Peter Liscovius

URL:
  http://savannah.gnu.org/task/?6418

 Summary: savannah login weired
 Project: Savannah Administration
Submitted by: peterdd
Submitted on: Montag 22.01.2007 um 17:28
 Should Start On: Montag 22.01.2007 um 00:00
   Should be Finished on: Montag 22.01.2007 um 00:00
Category: None
Priority: 1 - Later
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

I don't know if that is the right place here, but I want to report a bug of
savannah.gnu.org website and haven't found a better place yet.

When using a browser (namely konqueror) with some restricted cookie settings
(sending cookie only to sending server) the login fails and the response
claims that the cookies are set off in browser. But that is false alarm
because it works perfectly on other sites which save the sessionid in
cookies.

Further I dislike the default activation of autologin to other sites
(savannah.nongnu.org) in the login form. 

ps: Made duplicate entry in 'gnu help wanted' because I'm not sure where to
post best for that topic.




___

Reply to this item at:

  http://savannah.gnu.org/task/?6418

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/