Giters

OpenRA / openrauseraccounts

Connect phpBB forum accounts to OpenRA installations

Home Page:https://forum.openra.net/ucp.php?i=232

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Move repository to OpenRA organization

opened this issue · comments

commented

It would be very cool if the repository could move over to OpenRA and I have no objections against passing over ownership, losing push access or other privileges. I consider my job with things I can do independently almost done and future implementations would probably need to be discussed between the OpenRA devs. I already feel a bit out of place when suggesting or even implementing things which affect their project.

The changes, issues or recently added and assigned milestones represent my very limited experience in coding and software development (this is my first real project) and I would be glad if more experienced people took the lead here while I stay contributing and learning. In fact, I wouldn't want to have push access to an official OpenRA repository considering how often I break things. There are still a lot of things that I would like to implement as I have fun working on this (yes, php can be fun!) but from here on I would feel happy to do it on a pr basis.

If this is possible would have to fix things like formatting in files and remove outcommented WIP code before.

commented

My plan here is to:

  • Wait until you are happy with the state of the repository for a 1.0 (or maybe 0.9?) release.
  • Squash all commits and make sure line endings etc are consistent.
  • Do a security review to make sure (to the best of my abilities) that there are no obvious holes that could be exploited to damage the forum.
  • Tag a release and deploy it to the forum.
  • Move the repository to the OpenRA organization, keeping you as a mainainer for this.

If there are any partial features that you don't think you'll be able to finish on the timescale of the playtest please list them them here, and I can move them to a branch so that the partial functionality won't be exposed in the initial deployment.

commented

I can not reliably say if #13 and #18 will be ready in time which are the two features that I would like to be included in the first release. If it turns out that they won't be ready by then, I'll branch off a 'development' branch including all WIP features and remove them from master. Agree with your plans and will do my best to deliver in time.

commented

I would ideally like to act on this over this coming weekend. Is this too soon for you?

commented

#13 is 80% finished and #18 can probably be implemented without too big problems after this. Am confident to finish the features on my end until then and clean up all files as mentioned. Aside from badges and all the other work you have to do I hope you find time to check #23.

commented

Overview of pending todos:

  • #18: Finished but has some limitations: once a default badge is selected, you can not remove all default badges from the profile but only add/change them. Removing the last selected needs a reset all button. Needs +1 if we can leave it like it is for the moment.

  • #7: Pending but is just copy/paste.

  • #20: Can/will be deleted

  • #25: Pending, will use confirm_box() that only triggers when there is no (revoked) key in the db for the user.

  • ACP: Replace file selection with a textbox to enter URL for badge icon.

  • ACP: Radio input for badge_os and badge_mod. The module is useless without them.

  • ACP: New mode to add badge types.

  • ACP: Show how many badges are linked to a badge type .

  • ACP: Show how many users use a badge.

  • #14: Changed everything to reference to 24px icons, unless we want to leave that open to gather testing results I consider this done.

  • #15: Pending, will be a SELECT 'revoked' ... WHERE fingerprint = $fingerprint after if($duplicates) and then return the appropriate duplicate error.

  • Check functionality of all features/buttons/critical errors (duplicates...) after everything above is done

  • Grammar and spelling check for descriptions, titles etc. and general +1 for them

commented

re badge_os and badge_mod: we will want a different way to implement these - adding a new database column for each default badge category doesn't scale. For now we can use either one category for everything or hardcode the badge ids in the templates. We can't afford to delay the first release over getting this right.

commented

You are right, my idea here is to add a openra_badge_types table with columns badge_type_id and badge_type_name and add the column badge_type_id to openra_badges. This would allow to retrieve all default badges in one query instead of one per "type" like now and order the result set by badge_type_name for example.

commented

Ready to move.

commented

There have been some more things I had to do:

  • Set line endings to LF in all files.

  • Use consistent indentation in all PHP files, tab size is 8 spaces.

  • Remove WIP code from acp_badges.php for the WIP module to refer badges to users.

  • Minor code change: S_ADD in acp_badges.php used isset() to check if a array is empty, changed to use empty(). This fixed the reset button not showing up in the ACP badges / types interface.

  • Remove prototype files from gitignore and remove them from the local repo. Added /.vscode for my personal editor settings.

  • Changed my nick in the authors file.

I have tested the features after the changes and everything seems to work.

commented

There have been some more changes since the last comment and the repository has been moved to OpenRA/openrauseraccounts, so I'm happy to close this.