On Tue, Nov 17, 2015 at 2:58 PM Xavier Lamien <laxathom(a)fedoraproject.org>
> On Tue, Nov 17, 2015 at 11:38 AM Pierre-Yves Chibon <pingou(a)pingoured.fr>
>> On Tue, Nov 17, 2015 at 11:04:20AM +0100, Pierre-Yves Chibon wrote:
>> > This is without checking the changes in unique constraints where we
>> might have
>> > a few other surprises.
>> After looking more into this, it seems the only fields where we will run
>> 'problems' are `ircnick` and `email_token` that FAS3 requires to be
>> unique while
>> FAS2 doesn't.
>> I run the following query on the DB:
>> SELECT username, ircnick, status
>> FROM people
>> WHERE ircnick IS NOT NULL
>> AND ircnick != ''
>> AND status = 'active'
>> AND ircnick IN (
>> SELECT ircnick
>> FROM people
>> WHERE status = 'active'
>> GROUP BY ircnick
>> HAVING COUNT(ircnick) > 1
>> ORDER BY ircnick, username;
>> This returned 70 rows, so at least 35 persons have at minimum 2 accounts,
>> active, set with the same ircnick.
>> I propose that we contact them and kindly ask that they either remove the
>> ircnick from one of the accounts or just deactivate it.
>> For the email_token, we have two different account with the same token,
>> and a
>> few with a token's whose value is ''.
>> (Also: FAS3 requires email_token to be unique, but not password_token,
>> should we
>> make this consistent?)
>> Some more questions for the migration:
>> - Do we migrate disabled accounts?
>> - Do we migrate accounts who last_seen date == the creation date ?
> yes, since they will be set as inactive.
> globally, as we do not delete any account, we should keep them.
> They will no showed up in the UI for en-users but admin's panel.
> Or were you thinking about clean up accounts?
On Tue, Nov 17, 2015 at 2:56 PM Xavier Lamien <laxathom(a)fedoraproject.org>
> On Tue, Nov 17, 2015 at 11:05 AM Pierre-Yves Chibon <pingou(a)pingoured.fr>
>> Good morning everyone,
>> I started looking at what it will take to migrate data from FAS2 to FAS3.
>> Here are my findings.
>> First of all the DB schemas:
>> FAS2: http://ambre.pingoured.fr/public/FAS2.png
>> FAS3: http://ambre.pingoured.fr/public/FAS3.png
>> * Tables to delete in FAS2:
>> - session
>> - migration_version
>> - visit
>> - vistit_identity
>> - configs
>> - requests
>> - samadhi_associations
>> - samadhi_nonces
>> - group_roles
>> * Tables of FAS2 I do not know what to do with:
>> - Log
>> We have some logs in the DB, we might be able to convert them but the
>> of information missing for the new log table (people_activity_log)
>> might not
>> make it worth
>> - bugzilla_queue
>> There are a few entries in there, but I do not know what it is meant
>> for nor
>> used by
>> * Tables to migrate
>> - person_roles -> group_membership in FAS3
>> - person_roles_fpca -> group_membership in FAS3
>> -> I guess created when we changed from CLA to FPCA so to be merged
>> in the
>> same one as above
>> - groups -> group in FAS3
>> - people -> people in FAS3
>> * Fields that changed
>> username : FAS2 = varchar(32) -> FAS3 = varchar(255)
>> fullname : FAS2 = human_name -> FAS3 = fullname
>> avatar : FAS2 = blog_avatar? -> FAS3 = avatar
>> password : FAS2 = varchar(127) -> FAS3 = text
>> gpg_id : FAS2 = gpg_id -> FAS3 = gpg_keyid
>> emailtoken: FAS2 = emailtoken -> FAS3 = email_token
>> passwordtoken: FAS2 = passwordtoken -> FAS3 = password_token
>> status : FAS2 = text -> FAS3 = int
>> alias_enabled: FAS2 = alias_enabled -> FAS3 = email_alias
>> last_seen : FAS2 = last_seen -> FAS3 = last_logged
>> name : FAS2 = varchar(32) -> FAS3 = varchar(40)
>> url : FAS2 = url -> FAS3 = web_link
>> groupe_type: FAS2 = varchar(16) -> FAS3 = int (Foreign Key)
>> creation : FAS2 = creation -> FAS3 = created
>> joinmsg : FAS2 = joinmsg -> FAS3 = join_msg
>> user_can_remove: FAS2 = user_can_remove -> FAS3 = self_removal
>> For this table I have a problem with these fields in FAS3:
>> ``need_approval`` and ``requires_sponsorship``?
>> What is the difference? Which corresponds to ``needs_sponsor``?
> There were no real difference in between those two in FAS2 both were doing
> the same thind.
> In FAS3, the need_approval boolean is used when the group doesn't provide
> "sponsor" role.
> in this context, groud's admin can approve users without having (or being)
> a sponsor's role (like in fas2) which actually doesn't mean anything for
> this group's purpose.
>> role_type: FAS2 = role_type (text) -> FAS3: role (int)
>> role_status: FAS2 = role_status (text)-> FAS3: status (int)
>> sponsor_id: FAS2 = sponsor_id -> FAS3: sponsor
>> person_id: FAS2 = person_id -> FAS3: people_id
>> creation: FAS2 = creation -> FAS3: creation_timestamp
>> approval: FAS2 = approval -> FAS3: approval_timestamp
>> Xavier, could you confirm that this mapping is correct? Should we look
>> being a little closer to the FAS2 model? (For example in the
> I don't think we should. This will make think more complicated by adapting
> fas3 code
> which come with a new architecture.
> Also for change such as the length of the password field, since we hash the
>> password, does it make sense to use a text field there since they will
>> all be
>> of the same size?
> If the the length from fas2 is the same as fas3, not really.
>> Then there is the question of the integer-based status (in the `people`
>> and in the `group_membership` table). Is the mapping documented somewhere?
>> Does it fit with the old status model?
>> Another question will be regarding the certificates, Xavier, will we be
>> able to
>> migrate certificates information to the new tables?
> We should be able to. what king of info is being missed in fas3?
Another day, another release.
I just cut and pushed a new release of mdapi: 2.2.3
It's a simple bugfix release, making official a hotfix I made yesterday that
fixed displaying the /branches endpoint.
Here is the changelog:
* Tue Nov 24 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 2.2.3-1
- Update to 2.2.3
- Fix the branches endpoint (un-instantiated variable)
Good morning everyone,
Yesterday and this morning I cut a new version of mdapi: 2.2.1 and 2.2.2.
The version 2.2.1 made it to stg, where we spot a bug which got fixed in 2.2.2.
The basis for these two versions was simply to have the links on the front page
work, whether you're accessing the application via:
https://apps.fedoraproject.org/mdapi/ or https://apps.fedoraproject.org/mdapi
Here are the changelogs:
* Mon Nov 23 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 2.2.2-1
- Update to 2.2.2
- Fix accessing the configuration to adjust the link on the front page
* Sun Nov 22 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 2.2.1-1
- Update to 2.2.1
- Fix the links in the front page with it's accessed without trailing slash
I am Gaurav Kumar and I would like to introduce myself. Currently, I am
free time, I have also contributed to CakePHP documentation and built PHP
I am using different flavors of Linux for six years now with Fedora as my
primary choice. Being a Linux user and a programmer myself I planned to
start contributing and involve with the Fedora community. I have started
learning Python for last few days and would like to involve in Python based
projects in Fedora. It would be great someone guide me on how can I get
Just some quick notes on CSI variables as may people are submitting
They can't contain : in them as thats used as a variable seperator.
If you want to do multiple lines, thats ok, but you have to do:
(the | is important there, it tells jinja that there's mutiple lines
Also, you can't use * in the multiline ones, use - instead as a