madrypiotr / sdd Goto Github PK

There are no need for text editors (CKE or TinyMCE type) in the textarea fields, but it is necessary that the ONLY format of the new line is kept when the editor will enter it.
Without new lines and paragraphs, larger content is not very legible and looks very unprofessional.

PL

Nie są potrzebne edytory tekstowe (typu CKE lub TinyMCE) w polach textarea, ale konieczne jest aby był zachowany TYLKO format nowej linii, kiedy tak wpisze edytujący.
Bez nowych linii i akapitów większe treści są mało czytelne i wygladają bardzo nieprofesjonalnie.

Priorytet w realizacji nie podlega zmianom.
(priorytet w głosowaniu jest historią i takim ma pozostać)

XXX

Nie można dołączyć jako Członek Zespołu Realizacyjnego w Kwestii-Opcji.
W zwykłej Kwestii jest OK.

Ukończenie rozpoczętej przebudowy mechanizmu SSR.render.
Powiadomienia e-mail wychodzą wadliwe.

Doradcy należy uniemożliwić operowanie na priorytetach.
Przykład: priorytetowanie Kwestii - już nie ma dostepu
Podobnie należy wyłączyć jemu możliwość prorytetowania komentarzy i odwołań.
Nie może też inicjować komentarzy specjalnych, jak [Do Kosza] (już nie może), ale nowo dodany [Zrealizowana] (może) - trzeba jemu wyłączyć.
.
Doradca może:

• dodawać komentarze (dzdiała),
• dodawać odniesienia do komentarzy (dzdiała).

Przy okazji ...
Niech button ma kolor tła taki jak jego komentarz specjalny.

Still, e-mail is the basis of validation, and the identification of a person by the PID (pl -PESEL) number that we do not want to change.
Other profile data protect against inserting camouflage data (currently it is possible to type in place Name "x" and City "y" and other similar.
see: http://poradnik.drogimex.pl/2017/05/18/wyrazenie-regularne-sprawdzajace-podane-imie-i-nazwisko/

• Some regexes catching and validating such "jokes",

Zamiast zapamiętać i pobierać z bazy czas dodania,
Prezentowany jest zawsze czas aktualny po wejściu w szczegóły Kwestii.

.

Istniejące w templatce zmienne, nie wchodzą do listu. Najpierw oznaczyłem templatkę (5), aby mieć pewność, że to ona tu pracuje. Okazało się, że ona.
Wobec tego domyślam się, że nadal problemy leżą po stronie tych SSR.
Problem ten występuje jeszcze w kilku listach. Kiedy rozwiążemy problem tego - wskażę kolejne po testach.

Uwaga do ilustracji:
Oznaczone 1 - brak napisu w liście e-mail
Oznaczone 2 - też brak napisu w liście e-mail, ale to ostatecznie usunę, bo aplikujący w tym momencie jest dopiero w bazie, jako "Draft", a więc i tak się nie zaloguje, nie mając zresztą danych do logowania.

Testowalismy opcję nieprzyjęcia aplikującego.
CRON nie wie co zrobić z Kwestią w przypadku priorytetu 0 lub ujemnego w głosowaniu.
Powinien skierować Kwestię do Kosza.
Ta kwestia jest Kwestią aplikowania, więc aplikujący powinien otrzymać list
SDD\private\email_application_rejected.html
.

Po definitywnej rezygnacji z ingerencji admina w sprawy merytoryczno-organizacyjne, z kodu mależy usunąć wszelkie zależności (bloki kodu zawarte w if) odnoszące się do ewentualnego zalogowanego admina, a także całe szablony, które miały adminowi służyć.

Nie ukazują się szczegóły Kwestii aplikacyjnej.

• W kolekcji "usersDraft" - jest
• Na liście Kwestii - jest,
• Po kliknięciu w nazwę Kwestii - nie jest prezentowana w szczegółach Kwestii.

To się dzieje po dobraniu Kwestii do istniejącego ZR
Kiedy są kompletowani po kolei, to pokazywani są prawidłowo.

Pozostałą jeszcze adminowi operację na językach, również trzeba wzbogacić o tłumaczenie przez użytkowników-tłumaczy.

1. tłumaczenie serwisu (zakończone generowaniem regionalnego pliku JSON), a w przypadku istniejacego - aktualizowanie.
2. edycja istniejącego pliku JSON w tym samym trybie (tłumaczenia),
3. aktywowanie / dezaktywowanie języków dla wyboru przez użytkowników.

Docelowo logowania admina nie będzie (będzie nazwane logowaniem tłumacza).

Nie działają 4 button'y

W trzech miejscach:

• szczegółowy opis Kwestii,
• komentarz,
• odniesienie do komentarza,

trzeba zapamiętać znaki nowego wiersza, aby piszący akapitami miał je zachowane w widoku.
Obecnie, pisany tekst (np, jak powyższy) widziany jest przez użytkownika tak:

W trzech miejscach: - szczegółowy opis Kwestii, - komentarz, - odniesienie do komentarza, trzeba zapamiętać znaki nowego wiersza, aby piszący akapitami miał je zachowane w widoku.

Jest to mało przyjazne w czytaniu,

Although the user is set to pl, the data is taken from en.i18n.json

2017

Marzec | 1, 2, 3 |

Opis wstępny

Użytkownicy od 1-go do 5-go w prosty sposób rejestrują się w Systemie.
Następni Użytkownicy są już przyjmowani do Systemu w trybie aplikowania.
Aplikowanie kolejnych (od 6-go) Użytkowników generuje im Kwestie Osobowe, które są procedowane tak samo, jak każda inna Kwestia, czyli po przegłosowaniu staje się Kwestią w realizacji. Dopóki trwa realizacja Kwestii Osobowej, Osoba jest Członkiem Organizacji.
Takie procedury są celowe i zamierzone w projekcie.

Problem

Otóż, pierwszym 5. Użytkownikom System nie generuje Kwestii Osobowych. W wyniku tego są oni de facto "wyjęci spod prawa". Nie można ich oceniać ani (ewentualnie) - rozstać się z nimi.

UWAGA

Należy zachować funkcję tworzenia na starcie Systemu Zespołu Realizacyjnego ds. Osobowych i przydzielanie do jej składu sukcesywnie trzech pierwszych rejestrujących się Użytkowników.

Zaplątany średnik w lewym górnym rogu.

client\views\ustawienia\zgloszenieCzlonkow\add_honorowy.html

USTERKA 1. Pobranie języka.
W rejestracji już dobrze, ale w aplikowaniu bierze jeszcze z JSON-a ang.

... i dalej się to za Aplikującym ciągnie ...

Te usterki ciągną się od dawna. Niewłaściwe pobieranie zestawu JSONa
W przypadku przyjmowania nowego funkcją [Dołącz] (Aplikowanie).
.
1 list - info o wpływie aplikacji - PO POLSKU (prawidłowo)

.
2 list - wezwanie do walidacji - PO ANGIELSKU (NIEprawidłowo)

.
3 list - podanie danych logowania - PO ANGIELSKU (NIEprawidłowo)

...
lub nie są generowane? (to już działało)

Button dodania Opcji nie działa

Preparation of a guide.

During ...

Pierwszy list

1. W nagłówku listu ma być:
   Potwierdzamy wpływ aplikacji o przyjęcie jako Członka
2. W treści ma być:
   SDD
   { org_name }
   Szanowny { Imię Nazwisko }!

Do systemu: SDD - { org_name } wpłynęła Twoja aplikacja o przyjęcie.
Trwa głosowanie.
Po jego zakończeniu otrzymasz drugi list z danymi do logowania.
Dziękujemy!

--
Jest to automatyczna informacja z systemu SDD - { org_name }
Nie odpowiadaj na nią.
.

Do uporządkowania SSR.
Nie wszystkie e-mail'e (powiadomienia systemu) przychodzą kompletne.
Przykład poniżej.

.
Przykład prawidłowy z lutego br.

Z chwilą przejścia z głosowania do realizacji, a więc nadania Kwestii osobowej statusu "realizowana",
należy jednocześnie zamienić przedrostek "Aplikowanie" na:

1. w przypadku Członka - "Członek" - i18n --> {{glob.Member}}.
2. w przypadku Doradcy - "Doradca" - i18n --> {{glob.Advisor}}.

@MichalW proponuje:
Pozwolę sobie jeszcze zwrócić uwagę na Pana niezabezpieczone metody serwerowe:
Każdy (nawet niezalogowany) użytkownik może wykonać metodę np.:

Meteor.call('removeZespolRealizacyjnyDraft', {});
co spowoduje usunięcie pana dokumentów z bazy danych.
Należałoby sprawdzać this.userId.

Wszystko działa OK dopiero po wybraniu danego języka.
Na start, jak również po "ręcznym" przeładowaniu, klient widzi nazwy zmiennych (nawet ten zalogowany, który określił swój język w profilu).
Skoro użytkownik, klikając, otrzymuje pożądany efekt, to pewnie System "sam z siebie" będzie mógł to uczynić, trzeba mu to "powiedzieć" w kodzie.

Trzeba spowodować,

aby j.polski, który jest językiem domyślnym był faktycznie widziany "na dzień dobry".

Język domyślny jest zdefiowany w pliku: ... lib\constants.js

LANGUAGES = {
    DEFAULT_LANGUAGE: "pl"
}

Natomiast po zalogowaniu już tylko język Użytkownika.

Nie pamięta treści Regulaminu pomimo poprawnego zrealizowania Kwestii specjalnej (parametru globalnego

)

Potrzebna drobna korekta ...

Po głosowaniu Kwestia powinna zachować wielkość priorytetu i startować w realizacji z priorytetem, jaki miała na koniec głosowania.

We still lack functionality that will take advantage of the Registered Advisors.
You need to implement a mechanism to "pin" them to specific Issues already at the stage of deliberation. Of course, they should also accompany her during the implementation phase.
Members of the Implementation Teams will have professional help in this way. They should be able to recruit Advisers by nominating candidates for Advisers to register with the SDD at once with the assignment to a particular Issue at each stage.

Gdyby Doradca chciał zmienić swój status na Członka, trzeba opracować sposób prostszy, aniżeli aplikowanie "od zera".
Powinno to polegać na uzupełnieniu jedynie brakujących danych w stosunku do profilu Członka.
Oczywiście - w efekcie również powinna powstawać niczym nie różniąca się od innych - Kwestia aplikacyjna.

TO BARDZO PROSTE i z wykorzystaniem już istniejącego kodu nazwanego "[Do Kosza]" (UWAGA: zmieniłem wizualnie na "Do Archiwum", aby ludzi nie wyrzucać do kosza :) )
Bo też Kwestia Osobowa ma działać, jak każda inna Kwestia, a więc wyrzucenie "Do Archiwum" Kwestii Osobowej powinno równać się pożegnaniu się z użytkownikiem.
.
Póki co, w przypadku Kwestii Osobowej działa tak:

A więc znowu mamy okazję z tego alertu zrobić użytek i zamienić go na:
"Czy na pewno chcesz zaproponować usunięcie ... "
a) wersja dla Kwestii Osobowej: "... tego Użytkownika?"
b) wersja dla innych Kwestii: "... tej Kwestii?_"
[TAK] [NIE]
A dalej już dotychczasową ścieżką - tworzenie Komentarza specjalnego dla decyzji ogółu ...

Powyższa treść już jest zmieniona w plikach JSON, aby odpowiadały nowej sytuacji.

Place the [Relized] button in the details of the Issue, which is in the Implementation panel.
Result - creation of a special comment for placing Issue in the panel "Realized".
Tip:(procedure already developed for the [To Trash] function).

Najpierw sprawdzić, czy może ta funkcja nie może pracować na localhost, gdzie testuję? Może na serwerze zdalnym zadziała?

• Pierwszych 5-ciu użytkowników wprost rejestruje się - (działa).
• Od tej pory System przestawia się w tryb aplikowania - (działa).
• Teraz System oferuje przycisk [Dołącz], który angażuje m. inn.:
  SDD\client\views\account\czlonek_zwyczajny_form.html
  SDD\client\views\account\czlonek_zwyczajny_form.js
  SDD\client\helpers\methods_users.js

... niestety - po prawidłowym wypełnieniu formularza, kliknięcie submit'a [Aplikuję o przyjęcie]
nie powoduje poprawnej akcji dodania w Systemie Kwestii Specjalnej w kategorii "Osobowa".
addIssueOsobowa, lub addKwestiaOsobowa
Formularz nie znika, chociaż ponowna próba aplikowania z tym samym e-mail'em kończy się komunikatem, że już jest w bazie taki użytkownik. Został poprawnie wpisany do bazy oczekujących w kolekcji usersDraft.
Nie pojawia się on jednak na wykazie Użytkowników, co jest prawidłowe, ponieważ najpierw powinien się pojawić jako Kwestia Osobowa na wykazie Kwestii do zatwierdzenia przez Ogół w głosowaniu.
.
Ta procedura wcześniej działała poprawnie.
Na http://www.syncodec.net działa (nie opanowałem jeszcze deploy na NodeJS). Może prace rozwojowe na localhost spowodowały gdzieś wprowadzenie jakiegoś błędu lub usunięcia istotnego fragmentu,

Widać, że nie ma do czego nawiązać...
Być może należy zająć się tym dopiero po zafix'owaniu #8
.

@MichalW proponuje:
... dodać odpowiednie allow/deny:
http://docs.meteor.com/api/collections.html#Mongo-Collection-deny