Development/To-do - Revision history

Admin: Admin moved page To-do to Development/To-do without leaving a redirect

2021-02-13T22:29:15Z

Admin moved page To-do to Development/To-do without leaving a redirect

Admin: Admin moved page How it works/For administrators/To-do to To-do without leaving a redirect

2020-06-28T15:57:09Z

Admin moved page How it works/For administrators/To-do to To-do without leaving a redirect

Admin at 23:18, 27 June 2020

2020-06-27T23:18:09Z

Admin: Admin moved page How it works/To-do to How it works/For administrators/To-do without leaving a redirect

2020-06-21T10:59:11Z

Admin moved page How it works/To-do to How it works/For administrators/To-do without leaving a redirect

Admin: Admin moved page To-do to How it works/To-do without leaving a redirect

2020-06-21T08:26:56Z

Admin moved page To-do to How it works/To-do without leaving a redirect

Admin at 05:41, 17 June 2020

2020-06-17T05:41:17Z

Admin at 20:50, 26 April 2020

2020-04-26T20:50:37Z

Admin at 19:54, 25 April 2020

2020-04-25T19:54:26Z

Admin at 09:29, 25 April 2020

2020-04-25T09:29:26Z

Admin at 09:29, 25 April 2020

2020-04-25T09:29:06Z

← Older revision		Revision as of 23:18, 27 June 2020
Line 35:		Line 35:

	* create a form "class" to solve the problem of determining relationships (join) between courses and students from the page structure (not a good practice because the structure can change, for instance students may have multiple courses as subpages or a course may have multiple students as subpages). If we only rely on "classes", we organize things like that: personal data of students are always called as page and subpages of the form student. Then we create a class still on the private wiki with fields: course url (public information of the course: the "class" represent the set of participants of a given course), participants: followed by the list of participants, then we can have also multiple classes referring to the same course, eg. class of Monday-Wedn. and class of Tue-Thue, and even further fields...		* create a form "class" to solve the problem of determining relationships (join) between courses and students from the page structure (not a good practice because the structure can change, for instance students may have multiple courses as subpages or a course may have multiple students as subpages). If we only rely on "classes", we organize things like that: personal data of students are always called as page and subpages of the form student. Then we create a class still on the private wiki with fields: course url (public information of the course: the "class" represent the set of participants of a given course), participants: followed by the list of participants, then we can have also multiple classes referring to the same course, eg. class of Monday-Wedn. and class of Tue-Thue, and even further fields...
		+
		+	'''Done''' -- remove the url from the form "class" and ensure the class name correspond
		+	to the course name on the public wiki (as specified in the site's row)
		+
		+

	* Create a namespace for the project "Culturaitaliana" or "CI" and put there all relevant pages, for instance "[organization]/Frontend Index", "Sidebar_LoggedIn", "Sidebar_SysOp", [organization]/Banner.jpg, etc. --- ok for those not belonging to an organization but in the latter case this conflicts with editing rights ...		* Create a namespace for the project "Culturaitaliana" or "CI" and put there all relevant pages, for instance "[organization]/Frontend Index", "Sidebar_LoggedIn", "Sidebar_SysOp", [organization]/Banner.jpg, etc. --- ok for those not belonging to an organization but in the latter case this conflicts with editing rights ...

@@ Line 15: / Line 15: @@
 **List of meeting participants
-and create a main page reflecting this structure with cards similar to the public mainpage
+and create a main page reflecting this structure with cards similar to the public mainpage '''DONE'''
 *Create a form "Newsletter", with fields: Date, audience subset/segment, message (this will be filled in by the frontend/nodejs script, but the sending could be also managed in the wiki itself) '''(DONE)'''
@@ Line 30: / Line 30: @@
 *create a demo private wiki (in this case or public or with a test account with public password) for showcasing
 *form "member" (or "organization member") : add field "groups": a select with the list of existing group and the ability to create a new one.
 This requires another form-template "add group", and the ability from a script in the form to create a new wiki page with that template through mw.api
@@ Line 50: / Line 51: @@
 *debug the files subfolder related functions
-*complete the pure-html forms (not PageForms) for retrieving contact information on the main page (server-side)
+*complete the pure-html forms (not PageForms) for retrieving contact information on the main page (server-side) '''DONE'''
 *change the upload folder name from "files" to "media"
@@ Line 75: / Line 76: @@
 (<u>this page should also provide a way to save contacts through csv in the form organization member of the private wiki</u>)
-*(organization's page) create a menu for languages (as described in my communication of 3th of April) and a tab on the page header when a page is localized in multiple languages
+*(organization's page) create a menu for languages (as described in my communication of 3th of April) '''DONE''', and a tab on the page header when a page is localized in multiple languages
 *create the site's home page (like scambieuropei)
-*show advertisements set by organization, books suggestion, digital libraries, opportunities (and other forms for general purpose) on the right panel/column through nodejs-socket.io-axios
+*show advertisements set by organizations, with books suggestions, digital libraries, opportunities (and other forms for general purpose) on the right panel/column through nodejs-socket.io-axios
-*(organization's page) handle selection of pages based on the router event (so the navigation menu should contain router-links) ('''done''')
+*(organization's page) handle selection of pages based on the router event (so the navigation menu should contain router-links) ('''Done''')
-*mention the libraries / technologies which we are using, eg. nodejs, vuejs, mediawiki, knex, lodash, quasar framework, esprima, htmlparser2, cheerio, semantic mediawiki (and other relevant mediawiki plugins)
+*mention the libraries / technologies which we are using, eg. nodejs, vuejs, mediawiki, knex, lodash, quasar framework, esprima, htmlparser2, cheerio, semantic mediawiki, language detect, jsonwebtoken, mediasoup, nodemailer, email templates (and other relevant mediawiki plugins)
 *add library to detect main language of a given page ***we could use the following https://github.com/NaturalNode/natural (even for topic categorization of contents) *** no, we are using "languagedetect.com" and google, see frontend script (nodejs)
@@ Line 97: / Line 98: @@
 * home page (fare alla fine sulla base di tutto il materiale e le funzioni da rappresentare)
 * page: organizations: aggiungere icona "exit" sulla toolbar che rimanda alla home page; verificare se le pagine possono essere visualizzate sulla base di temi, ad es. handlebars (v. "ghost"), anche se poi si va ad utilizzare uno solo per tutte le organizzazioni-- per omogeneità
 * page: newsletters:
 ** signin con credenziali wiki privato (in questo caso deve essere inserito anche l'username della organizzazione) oppure pubblico
 ** view a: lista delle newsletter già inviate
 ** view b: lista dei membri (audience) della organizzazione (recuperati dal wiki privato), aggiungi membro (vai a view b-a) oppure aggiungi lista (csv-comma separated values)
 ** view b-a: modifica membro (form "clone" di quella sul wiki privato)
 ** view c: lista dei gruppi (aggiungi, rinomina, cancella, come in "assigni")
 ** view c-a: modifica gruppo (aggiungi, rimuovi contatti, sulla base dell'elenco completo dei membri)
 ** view d: creazione newsletter: aggiungi uno o più gruppi (incluso "tutti i membri"), aggiungi singoli contatti; oggetto; casella di testo; pulsanti: plain test / rich text / html template (ckeditor); pulsante invio
 ** una volta inviata la newsletter viene salvata nel sito wiki privato, form newsletter
 * page: classes/[nome classe]
-** overview (pubblico: informazioni sul corso, sulla base della form language_courses), campo per inserire email e pulsante sign in (se l'email appartiene ad uno degli studenti registrati nel corso (form language course student), invia un codice a questa email oppure chiede di scegliere una password
+* page: classes/[nome classe] ('''Done''')
 ** pagina privata dello studente (l'url è la stessa) visualizza la pagina dello studente creata nel wiki privato, inoltre: informazioni sugli altri partecipanti del corso; interfaccia per la lezione in videoconferenza
 * funzioni da aggiungere alla pagina "organizations/[nome organizzazione]"
 ** paying content: alcuni contenuti possono essere fruibili a pagamento e quindi registrati nel wiki privato; modalità di fruizione: si acquista una combinazione fra numero di parole e tempo speso nella lettura (da valutare meglio), es. 10 000 parole a 5 euro, non relativo ad uno contenuto, bensì a contenuti della intera biblioteca; implementare pwa (progressive web application) in modo da rendere i contenuti fruibili anche online ; implementare una sorta di lettura "paragrafo per paragrafo", con statistiche inviate all'autore, etc.
 * sulla barra destra, in tutte queste pagine, vengono sempre visualizzati gli annunci pubblicitari, opportunità, digital libraries, reading suggestions, etc.
 * prendere in esame tutte le form e valutare come il sito front end può essere arricchito sulla base di esse
 * Riorganizzazione della pagina della organizzazione:
 ** url: culturaitaliana.org/istitutoculturaitaliana (organizzazione username)
 (lo username viene assegnato al momento dell'iscrizione)
 ** culturaitaliana.org/istitutoculturaitaliana/pages (attuale sito frontend della organizzazione, con tutte le pagine del wiki pubblico)
 ** culturaitaliana.org/istitutoculturaitaliana/newsletters (signin amministratori)
 ** culturaitaliana.org/istitutoculturaitaliana/classes (signin studente)
 ** altre pagine che non rientrano nella tipologia di articolo ma che offrono funzionalità (es. "questionari")
@@ Line 130: / Line 153: @@
 organizzazione di "classes":
-* scheda studente wiki privato, eventualmente con sottopagine
+* scheda studente wiki privato, eventualmente con sottopagine ('''Done''')
 * class: videoconferenza con tutti gli altri studenti, e chat
@@ Line 151: / Line 174: @@
 culturaitaliana.org/private-wiki/Istituto_cultura_italiana_(NGO) or culturaitaliana.org/private-wiki/istitutoculturaitaliana (private wiki)
 (the latest "Istituto_cultura_italiana_(NGO)" being a username while the first a page name)
-so that whatever folder not starting with wiki/ or private-wiki/ will be redirected to the frontend
+so that whatever folder not starting with wiki/ or private-wiki/ will be redirected to the frontend through a proxy
 use the library  https://www.npmjs.com/package/connect-history-api-fallback  if necessary
@@ Line 162: / Line 183: @@
 *Export all members of our organization in our private wiki (form member) (through a script)
 *(Export all communication with more than 1 recipient to the private wiki: this will require a further form, and is related to another phase of the project, regarding dissemination of literary works using a web app allowing to read them offline but at the same time tracking reading information etc..)
 ==Bugs==

← Older revision		Revision as of 20:50, 26 April 2020
Line 34:		Line 34:

	* create a form "class" to solve the problem of determining relationships (join) between courses and students from the page structure (not a good practice because the structure can change, for instance students may have multiple courses as subpages or a course may have multiple students as subpages). If we only rely on "classes", we organize things like that: personal data of students are always called as page and subpages of the form student. Then we create a class still on the private wiki with fields: course url (public information of the course: the "class" represent the set of participants of a given course), participants: followed by the list of participants, then we can have also multiple classes referring to the same course, eg. class of Monday-Wedn. and class of Tue-Thue, and even further fields...		* create a form "class" to solve the problem of determining relationships (join) between courses and students from the page structure (not a good practice because the structure can change, for instance students may have multiple courses as subpages or a course may have multiple students as subpages). If we only rely on "classes", we organize things like that: personal data of students are always called as page and subpages of the form student. Then we create a class still on the private wiki with fields: course url (public information of the course: the "class" represent the set of participants of a given course), participants: followed by the list of participants, then we can have also multiple classes referring to the same course, eg. class of Monday-Wedn. and class of Tue-Thue, and even further fields...
		+
		+	* Create a namespace for the project "Culturaitaliana" or "CI" and put there all relevant pages, for instance "[organization]/Frontend Index", "Sidebar_LoggedIn", "Sidebar_SysOp", [organization]/Banner.jpg, etc. --- ok for those not belonging to an organization but in the latter case this conflicts with editing rights ...

← Older revision		Revision as of 19:54, 25 April 2020
Line 32:		Line 32:
	*form "member" (or "organization member") : add field "groups": a select with the list of existing group and the ability to create a new one.		*form "member" (or "organization member") : add field "groups": a select with the list of existing group and the ability to create a new one.
	This requires another form-template "add group", and the ability from a script in the form to create a new wiki page with that template through mw.api		This requires another form-template "add group", and the ability from a script in the form to create a new wiki page with that template through mw.api
		+
		+	* create a form "class" to solve the problem of determining relationships (join) between courses and students from the page structure (not a good practice because the structure can change, for instance students may have multiple courses as subpages or a course may have multiple students as subpages). If we only rely on "classes", we organize things like that: personal data of students are always called as page and subpages of the form student. Then we create a class still on the private wiki with fields: course url (public information of the course: the "class" represent the set of participants of a given course), participants: followed by the list of participants, then we can have also multiple classes referring to the same course, eg. class of Monday-Wedn. and class of Tue-Thue, and even further fields...

← Older revision		Revision as of 09:29, 25 April 2020
Line 87:		Line 87:
	*post frontend/server scripts to a github public repository ? (see rather the following)		*post frontend/server scripts to a github public repository ? (see rather the following)

−	* ''' create an api interface for some common operations, like retrieve pages with a given form, and providing some "join" ''' (by this way it's not necessary to publish on github the frontend-server side script)	+	* ''' create an api interface for some common operations, like to retrieve pages with a given form, and providing some "join" ''' (by this way it's not necessary to publish on github the frontend-server side script)

← Older revision	Revision as of 15:57, 28 June 2020
(No difference)

← Older revision	Revision as of 10:59, 21 June 2020
(No difference)

← Older revision	Revision as of 08:26, 21 June 2020
(No difference)

← Older revision		Revision as of 09:29, 25 April 2020
Line 85:		Line 85:
	*complete page with api calls examples		*complete page with api calls examples

−	*post frontend/server scripts to a github public repository ?	+	*post frontend/server scripts to a github public repository ? (see rather the following)
		+
		+	* ''' create an api interface for some common operations, like retrieve pages with a given form, and providing some "join" ''' (by this way it's not necessary to publish on github the frontend-server side script)