wtorek, 10 września 2013

Menu w OpenERP 7.0

,
Załóżmy, że napisaliśmy nasz wspaniały nowy moduł dla OpenERP. Kod w Pythonie wygląda przyzwoicie i chcielibyśmy dać użytkownikom możliwość korzystania  z nowo powstałej funkcjonalności.
Użytkownik przyzwyczajony jest zazwyczaj, że po instalacji nowego modułu pojawi się menu związane z nową funkcjonalnością, która wykorzystuje właśnie nasz nowy moduł.
Przed dystrybucją takiego modułu, programista musi zadbać o poprawnie skonfigurowane menu.
W tym poście przedstawię sposób budowania menu od strony użytkownika. W kolejnych postach będę po kolei przedstawiał informacje, które będą tworzyły menu dla konfiguracji takiego modułu.

Gdy programista staje przed koniecznością utworzenia menu w OpenERP dla napisanego modułu, staje przed koniecznością stworzenia dwóch typów elementów:

menuitem - element menu mający bezpośredni skutek w samym menu OpenERP,

record - element odwołujący się do modelu ir.action.act_window, tworzący akcję, która "mówi" co OpenERP ma wyświetlić, gdy zostanie kliknięte menuitem odwołujące się do danej akcji.

W chwili obecnej może wydawać się to trochę zawiłe ale myślę, że przedstawiony przykład powinien rozwiać te obawy.

Niech nasz przykładowy moduł nazywa się "Students" i chcielibyśmy, żeby był dostępny poprzez przejście przez menu Sales -> After Sale Services -> Students. 

Kilka uwag:
A. Menu Sales instalowane jest domyślnie dla modułów CRM i/lub Sales
B. Menu After Sale Services domyślnie instalowane jest przez moduł crm_helpdesk
C. Menu Students jest elementem "aktywnym" odwołującym się do widoku tree naszego modułu - innymi słowy - kliknięcie w pozycję Students - umożliwia pracę z naszym nowo powstałym modułem.

Cały nasz kod związany z obsługą menu w pliku xml modułu wygląda tak:


<menuitem id="menu_sprzedaz" name="Sales" />
<menuitem id="menu_after_sale_services" name="After Sale Services" parent="menu_sprzedaz" />;
<menuitem id="menu_students" name="Students" parent="menu_after_sale_services" />;



Pierwsza linia odwołuje się do menu najwyższego poziomu- Sales. Dla naszego menu jest to root menu. Pytanie jakie nasuwa się w tym miejscu - skąd programista ma wiedzieć jakie nazwy (atrybut name) są przypisane do menu głównego?
Odpowiedź jest bardzo prosta - należy spojrzeć w katalogu Addons na źródła głównego modułu dla menu (w tym przypadku Sales lub crm). W tych plikach konfiguracyjnych odnajdziemy prawidłową nazwę root menu.
W drugiej linii w naszym testowym przypadku podmenu After Sale Services pochodzi już z modułu crm_heldpesk i tam należy odszukać definicję tego menu (prawidłowy parametr name) .

Każde menu bez podpiętej akcji pod to menu jest "nieklikalne". Oznacza to, że możemy rozwijać daną podgałąź ale do niej samej nie jest podpięta żadna czynność wyświetlenia listy elementów.

Read more

środa, 6 lutego 2013

Tworzenie modułów w OpenERP 7.0

,

Kilka uwag związanych z  procesem tworzenia modułów:


Przy tworzeniu nowych modułów w OpenERP 7.0 należy zwrócić szczególną uwagę na poprawną składnię plików XML opisujących widoki oraz akcje.
Osobiście preferuję walidację dokumentu pod względem poprawności dokumentu XML oraz walidację z użyciem XMLschema w opraciu o plik import_xml.rng znajdujący się w katalogu openerp.

Koniecznie restartuj serwer gdy instalujesz i odinstalowujesz tworzony moduł. Gdy zmieniałem nazwy kolumn spotkałem się z problemem "pamiętania" poprzednich nazw kolumn w module. Objawiało się to tym, że zmienione nazwy kolumn w definicji widoku były nierozpoznawalne przez OpenERP i powodowały błąd instalacji modułu. Gdy usunąłem wszelkie definicje widoków - moduł instalował się ze starymi nazwami kolumn, co można było zaobserwować bezpośrednio w bazie danych. Po odinstalowaniu modułu i wprowadzeniu zmian do definicji kolumn, należy zrestartować OpenERP. Po tych zabiegach system poprawnie widzi zmienioną strukturę kolumn modułu.

Po utworzeniu nowych pozycji menu należy wylogować się z OpenERP i zalogować ponownie aby zmiany były widoczne.

To tyle w telegraficznym skrócie z pola "walk" tworzenia nowych modułów.




Read more

czwartek, 18 marca 2010

Outlook vs Sharepoint 3.0

,

Jak na razie nie udało mi się odnaleźć informacji związanych z synchronizacją niestandardowych pól zawartych na witrynach WSS do outlooka (2007).

Przykładowy scenariusz:

  1. a. Utworzona została lista o nazwie "Pracownicy" typu "kontakty".
  2. b. Lista "Pracownicy" jest uaktualniana poprzez program startujący raz na dobę, który przegląda informacje w systemie kadrowym i w razie wymagań dodaje lub modyfikuje informacje zawarte na liście "Pracownicy".
  3. c. Z danych zawartych na liście "Pracownicy" korzystają inne listy (np. przypisane dokumenty, urlopy, itp).
  4. d. W momencie zwolnienia takiego pracownika ustawiany jest znacznik na liście "Zatrudniony" na "Nie".
  5. e. Widok "publiczny" prezentuje tylko zatrudnionych pracowników.

Według przedstawionego scenariusza w momencie zwolnienia pracownika wpis nigdy nie jest usuwany z listy "Pracownicy". W takim układzie wykorzystanie "Opcje -> Połącz z outlook"

2_polacz_z_outlook

zaimportuje wszystkie wpisy - łącznie z pracownikami, którzy nie są już zatrudnieni.

I tu powstało zasadnicze pytanie: Jak zaimportować pole "Zatrudniony" do Outlook'a w celu włączenia filtrowania po tym polu (pokaż mi wszystkich zatrudnionych pracowników)?

Zasadniczo, na tak postawione pytanie odnalazłem odpowiedź w pomocy technicznej Microsoft: tu.

W moim rozwiązaniu skorzystałem z nieużywanych pól. Do listy "Pracownicy" dodałem kolumnę z już istniejących ("Pole użytkownika 1") zmieniłem jej nazwę na "Zatrudniony". Od tego czasu wartość pusta informuje, że pracownik jest zatrudniony - w przeciwnym wypadku, system uznaje, że pracownik nie jest aktualnie zatrudniony.

Teraz po imporcie danych do outlooka należy (niestety) zmodyfikować ręcznie widoki poprzez ustawienie filtrowania na kolumnie "Pole użytkownika 1" (Dostosuj widok bieżący -> Filtruj -> Zaawansowane -> Pola kontaktów -> Pole użytkownika 1 -> Pole użytkownika 1 jest puste)

Aby zapobiegać modyfikacji pola przez użytkownika z poziomu programu Outlook , należy wdrożyć ItemReceiver , który będzie takim sytuacjom zapobiegał.

Jeżeli macie jakieś pomysły na "automatyczne" dodawanie filtrowania (np z poziomu Add-In) to byłbym bardzo wdzięczny........

Z pozdrowieniami
Piotr D. (jako Autor)
Read more

Peterson's Reaktywacja ;)

,

 

Dłuuuuuuuuugo nic nie pisałem - a co napisałem, to skasowałem. Czas na zmiany! Przechodzę (niestety) na komercyjną stronę Cyfrowych Mocy! Poprzednie wpisy dotyczyły Ruby on Rails i niewyobrażalnych zachwytów nad dwudziestoletnim (sic!) wzorcem projektowym MVC ;) Cóż to takiego jest - wtajemniczeni wiedzą a niewtajemniczeni ( i zainteresowani?) niech odnajdą wpisy związane z wyżej wymienionym terminem na wszechwiedzącej Wikipedii. Jak już wspomniałem - teraz - zajmować się będę w szczególności technologiami ze stajni Microsoft (Sharepoint Sercices 3.0 i programowaniem w technologii .NET).


O czym Was zawiadamiam
Piotr D. (jako Autor)
Read more
 

peterson's blog Copyright © 2011 -- Template created by O Pregador -- Powered by Blogger